Server Roles

The best way to think of Exchange 2007 server roles is to think of a server that has the necessary software and configuration to perform only a specific set of functions. This makes installing servers with dedicated functions much easier. Dedicated server roles are also more secure because only the necessary software is installed, thus reducing the attack surface.

The concept of server roles is not really new. In Exchange 2000/2003, to build a server for handling Internet messaging or inter-routing group messaging, you would install Exchange Server, flag the machine as a front-end server (optionally), and disable services such as the web service. To configure a machine as an Outlook Web Access or ActiveSync server, you would install Exchange, flag the Exchange server as a front-end server, and disable the information store and SMTP services. With Exchange 2007, the server roles are assigned when Setup is run.

Server Roles Overview

Exchange 2007 has made the assignment of specific server roles simpler by allowing the server roles to be designated at installation time. When you group together and install only the necessary services for a specific function, server installation is simpler and more secure and the server has less overhead. There are five basic server roles:

• Mailbox

• Client Access

• Hub Transport

• Unified Messaging

• Edge Transport

The Mailbox server role can be installed as a clustered mailbox server. In small and medium-size organizations, a single physical server will usually host more than one server role except in the case of the Edge Transport role. Edge Transport must run on its own server.

Mailbox Server Role

The Mailbox server role is responsible for mailbox and public folder databases and for allowing direct connectivity from MAPI/RPC clients. Clients such as Outlook 2003 or Outlook 2007 using MAPI/RPC will connect directly to the MAPI interface on the Mailbox server role. The Hub Transport and Client Access server roles are required for a fully functioning e-mail environment, but they do not necessarily have to be on the same physical server.

The Mailbox server role must exist on its own physical server if it is being installed as part of a clustered mailbox server environment. In that case, the Hub Transport, Client Access, and Unified Messaging server roles must be on separate physical hardware. A server handling a mailbox server role will typically be configured with significantly more RAM, hard disk space, and processor capacity than the other server roles.

High-availability options for Mailbox servers include local continuous replication, single copy clusters, and clustered continuous replication.

Local Continuous Replication

Local continuous replication (LCR) is a new technology for Exchange 2007. LCR is designed so that a production copy of a database can be synchronized and have a backup copy always ready to be put in to production if the primary copy becomes corrupted; the administrator initiates the switch over to the backup copy of the database. LCR is configured storage group by storage group, and each storage group can have only a single database in it.

When a server is configured to support LCR, an additional set of local disks should be allocated for the LCR transaction logs and for the backup copy of the database. These disks can be directly attached to the server or attached via storage area network (SAN) or Internet small computer systems interface (iSCSI). As transaction logs are completely filled and closed on the production copy of the database, they are copied to the backup location and committed to the backup copy of the database.

Note 

Local continuous replication is resource intensive since transaction logs are being copied and replayed to backup copies of a database.

Clustered Continuous Replication

Clustered continuous replication (CCR) is also a new technology for Exchange Server 2007. This technology is similar to LCR in that as transaction logs are filled, they are copied to a backup location and committed to a backup (or passive) copy of the database. However, with CCR, the implementation is in the form of a two-node active-passive cluster. When Windows 2003 clustering services are used, both the active and passive nodes must reside on the same IP subnet. The backup location is on the passive node; the transaction log files are pulled to the passive node and committed to the database on the passive node.

If the primary node of the cluster fails, the passive node automatically comes online and takes over handling the clustered mailbox server. Unlike Microsoft's previous implementation of Exchange clustering (single-copy clusters), there is not a single copy of the database and transaction logs that is shared by all nodes of the cluster.

Single-Copy Clusters

A Single-copy cluster (SCC) is the same technology that existed in earlier versions of Exchange. An active node of the cluster owns shared disks (usually on a storage area network or on network attached storage, or NAS). The cluster can consist of from two to eight nodes, but there must always be at least one passive node. There is only a single copy of the database and transaction log files, and they are located on the shared storage.

If an active node of the cluster fails, then one of the passive nodes will take ownership of the shared disks and database, mount the shared database, and start servicing clients for that particular clustered mailbox server (CMS); the CMS was formerly known as an Exchange virtual server (EVS) in previous Exchange cluster implementations.

Client Access Server Role

The Client Access server is considered a middle-tier server; this server role handles communications between non-MAPI clients and the Mailbox server role. In order to have a fully functioning e-mail environment, the Client Access server role must be functioning. The following are some of the functions of the Client Access server role supports:

• Outlook Web Access clients

• ActiveSync-enabled mobile devices

• Outlook Anywhere (RPC over HTTP) clients

• POP3 and IMAP4 clients

• Offline Address Book Web distribution

• Web services such as Autodiscover and the Availability service

• Web Services that require access to user mailboxes

The Client Access server accepts connections from these clients via HTTP, POP3, or IMAP4 and then passes requests on to the Mailbox server via MAPI over RPC. Each Active Directory site that contains a Mailbox server role must also contain at least one Client Access server.

High-availability options for the Client Access server role include implementing some type of network load-balancing solution such as the Cisco Local Director or Windows Network Load Balancing. The Client Access role cannot be configured on a clustered mailbox server.

Hub Transport Server Role

The Hub Transport server role is responsible for all message delivery regardless of whether the message is being delivered from one mailbox to another in the same mailbox database, a Mailbox server in the same Active Directory site, a server in a remote Active Directory site, or outside of the organization. At least one Hub Transport server role is required in each Active Directory site that contains a Mailbox server.

For internal mail routing, Exchange Server 2007 will automatically load-balance and fail over if more than one Hub Transport server exists in an Active Directory site. For redundancy in inbound SMTP mail from outside the organization, you have a couple of options. If inbound mail is coming directly into the Hub Transport servers, multiple MX records or network load balancing are good solutions. If mail is coming into a perimeter network solution such as Edge Transport or a third-party SMTP gateway, configure these solutions to use multiple internal Hub Transport servers.

For smaller organizations with a single server Exchange implementation, the Hub Transport server can perform most of the message hygiene functions performed by the Edge Transport server role to connect Exchange to outside world. However, separating message hygiene functions to a separate server role located on the perimeter network is more secure.

Unified Messaging Role

The Unified Message server role is considered a middle-tier system and is an entirely new concept for Exchange 2007. This server role integrates voicemail and inbound faxing with Exchange mailboxes. The Unified Messaging server requires an IP-based telephone switch or a traditional PBX-to-IP gateway (PBX stands for public branch exchange). The following functions are handled by the Unified Messaging server role:

• Provides voicemail for users of the IP-based phone system or through the PBX-to-IP gateway including voicemail greetings and options. Inbound voicemail is recorded as a WMA file and stored as a message in a user's Inbox.

• Accepts inbound faxes that are designated for specific mailboxes, converts the fax to a TIFF file, and stores that message in a user's Inbox.

• Allows a user to dial in to the Unified Messaging server to retrieve voicemail, listen to e-mail messages, review their calendar, or change appointments.

• Provides voice menus and prompting call menus acting as an auto-attendant system.

Edge Transport Role

The Edge Transport server role is an entirely new role. In the past, Exchange servers could be implemented as an additional tier of message hygiene protection. However, there are a number of reasons that you might not want to use Exchange servers as perimeter message hygiene systems:

• In order to process delivery reports, nondelivery reports, and address rewrites, the information store service must be running and the default mailbox database must be mounted.

• Placing an Exchange 2000/2003 server in the perimeter network requires many ports to be opened on the firewall from the perimeter network to the internal network.

• Allowing inbound e-mail directly to an Exchange server could jeopardize both Exchange and Active Directory.

For these reasons, a server role was developed that has many of the advantages of an Exchange 2007 server but can be made much more secure since it can run in the perimeter network as a stand-alone computer and does not require Active Directory membership. The following are some of the characteristics of the Edge Transport server role:

• The Edge Transport server role should be deployed in the perimeter network.

• It can be managed with Exchange Management Shell scripts and the Exchange Management Console in much the same way a regular Exchange server is managed.

• The only components required to run the Edge Transport role are the message transport system and an instance of the Active Directory Application Mode (ADAM) database.

• Features such as transport rules can be implemented in the perimeter network and provide message policy enforcement for messages entering or leaving the organization that is separate from that provided on the internal network.

• Connectivity between internal Hub Transport servers and Edge Transport servers can be authenticated and the data stream encrypted.

• The content filter functionality and other anti-spam and message security tools are built in, as is the ability to add third-party content filtering/message hygiene tools.

• Microsoft Forefront Security for Exchange Server can be employed on the Edge Transport server role for virus detection and quarantine.

For medium and large organizations, higher availability comes in the form of installing multiple Edge Transport servers and providing load balancing either using multiple DNS mail exchanger (MX) records, network load balancing, DNS round robin, or failover using multiple Internet connections.

Microsoft and Deployment Planning

Early in the Exchange 2007 life cycle, Microsoft defined some new terminologies, acronyms, and organization types that are used when designing and deploying an Exchange 2007 organization for businesses of different sizes. We felt it important to define these terms here so that there will be less confusion when reading both this book and the Microsoft documentation.

Using some of these terms, Microsoft has attempted to more clearly standardize design methodologies and approaches to deployment of Exchange in order to simplify Exchange operations.

The first of these terms is Service Delivery Location (SDL). The SDL is essentially the location of your servers. In a small organization, the SDL may be a secured and environmentally controlled closet within your own facility or it could be operated by a service provider or located at a colocation site. In a medium-size or large organization, an SDL may be distributed through many data centers in dozens or hundreds of locations throughout the world or it could be a consolidated, centralized data center with hundreds of servers servicing clients worldwide.

This brings us to the location of the actual clients, or the Client Service Location (CSL).This is the location from which your clients access the services you are providing. In a small organization, the CSL may be on the same physical LAN as the SDL, while larger organizations may see the CSL span countries, continents, or the entire world.

To simplify deployment concepts, Microsoft has defined four types of organization models representing topologies in which Exchange 2007 may be deployed. These are the simple, standard, large, and complex organization types. There is no exact formula for figuring out exactly which organization type might describe your organization. The physical distribution of your user community, your organization's high-availability requirements, your organization's fault tolerance requirements, the volume of data that your users process, and other factors will all influence the organization model that you choose or a variation on these models that you choose to create yourself.

Tip 

It's important to understand that there might not be an organization model that describes your organization exactly.

Simple Exchange Organizations

A simple Exchange organization is well suited for organizations with under approximately 200 mailboxes. Please note that "200 mailboxes" is somewhat arbitrary since organizations with either more or fewer mailboxes may fit in to this category depending on their user community, requirements, and messaging load. The simple organization has a single Exchange 2007 server that is running on the same physical machine as the organization's domain controller. The Exchange 2007 server handles the Mailbox, Hub Transport, Client Access, and Unified Messaging roles. The optional Edge Transport server role must still be on a separate physical server and should be located in the perimeter network.

In a simple Exchange organization, the users and the Exchange server are usually located in the same physical location, but that is not fixed rule. Even small organizations have telecommuters and users that access their organization using mobile technologies. Although the SDL is usually in the same location as the users, an emerging trend is for even smaller organizations to locate their server resources in a colocation site that provides Internet connectivity, power conditioning, backup power, air cooling, and physical security services. Another trend is to outsource the messaging functions entirely.

Note 

Organizations considering a single-server deployment that fits the simple Exchange organization model should consider a Microsoft Windows Small Business Server deployment. All of the components are tested together much more thoroughly (such as running Exchange Server on a domain controller).

Providing multiple layers of message hygiene and security for simple Exchange organizations would come in the form of a reverse proxy to handle inbound HTTP requests and an Edge Transport server in the organization's perimeter network. Figure 2.3 shows a simple Exchange organization that is separated from the Internet using Microsoft ISA server and a perimeter network.

Figure 2.3: Protecting a simple Exchange organization

Microsoft also offers an additional service called Exchange Hosted Filtering that allows organizations to direct their inbound mail to Microsoft's servers. The Hosted Filtering service inspects mail for viruses and spam and then passes the mail on to your servers. If you have purchased Enterprise client access licenses for all of your users, then this service is included.

Inbound SMTP mail from the Internet is directed to the Edge Transport server, which is located in the perimeter/DMZ network. Inbound e-mail is inspected in the perimeter network for viruses or spam and message transport rules can enforce organizational policies on messages arriving from the Internet.

Inbound Outlook Web Access, ActiveSync, and Outlook RPC over HTTP connections terminate at the Microsoft ISA Server 2006 firewall; ISA Server acts as a reverse proxy, inspecting the inbound HTTP requests and then passing them on to the internal Exchange 2007 server's client access components.

Standard Exchange Organizations

The standard Exchange model is by far the most common and flexible of the four Exchange server organization models. It will also be the organizational model most commonly found in organizations with from a few hundred to potentially tens of thousands of mailboxes. An organization will choose the standard Exchange model if any one of the following is true:

• Need to support more than approximately 200 mailboxes

• Require dedicated Exchange servers

• May need to split Exchange server roles among multiple physical servers

• Require dedicated domain controllers

• Need to support clustered mailbox servers

• Need to support more than one service delivery location (SDL)

• Require more scalability or infrastructure fault tolerance than the simple Exchange model can support

The standard Exchange organization is more scalable than the simple Exchange organization. Exchange servers are usually installed as member servers rather than on a domain controller. Exchange servers may span multiple Active Directory sites and server roles may be dedicated to specific physical servers rather than a single physical server. In this model, a single Active Directory forest is also required.

A standard Exchange organization with between a few hundred and a few thousand mailboxes might look like the one in Figure 2.4. In Figure 2.4, this organization has only a single SDL and requires high availability and redundancy. The Mailbox server is clustered to provide high availability for the mailbox databases while the Client Access and Hub Transport roles are both installed on two physical servers. By combining these two roles on two servers, the organization can provide better availability for message transport and web clients.

Figure 2.4: A standard Exchange organization

The organization could scale to as many as five Active Directory sites with Exchange 2007 servers and multiple Internet access points but still be considered a standard organization. The number of mailboxes is somewhat less of a factor here than the organization's needs. A company that places greater importance on its messaging needs and availability will find itself with dedicated servers and Exchange servers installed as member servers. When designing an Exchange organization for a company that meets this profile, the administrator will have to take into consideration the business needs, budget constraints, and availability requirements of the organization.

Large Exchange Organizations

Large Exchange organizations are the most scalable of the Exchange organizational models; they allow an Exchange organization to support tens of thousands or hundreds of thousands of mailboxes. A large Exchange organization can have the same characteristics a standard Exchange organization has plus the following:

• More than five Active Directory sites and multiple SDLs

• Multiple CSLs

• Multiple Active Directory domains within a single Active Directory forest

Although the large Exchange organization is certainly more scalable than the standard Exchange organization, the skills required to manage and build a standard Exchange organization do transfer upward to the large Exchange organization.

Complex Exchange Organizations

Complex Exchange 2007 organizations represent increasing complexity of Exchange 2007 in businesses that might have multiple Active Directory forests and resource forests or that host multiple companies within the same Exchange organization. In addition to the scalable features of a standard or large Exchange organization, the following are some of the characteristics of a complex organization:

• Multiple Active Directory forests with recipient replication using tools such as Microsoft Identity Integration services

• Multiple-organization support or support for multiple subsidiaries or business units in a single Exchange organization

• Integration with external Exchange organizations such as when a new business unit has been acquired but not merged in to a single organization

• Public folders, free and busy information, or shared calendaring between multiple organizations all using Exchange Server 2007

Size is often not the determining factor when designing and deploying a complex Exchange organization. In some cases, due to business requirements, even an organization with fewer than 1,000 mailboxes may find itself requiring multiple forests or other situations that require a complex Exchange organizational design.

Combining or Splitting Server Roles

A common question with respect to Exchange 2007 and server roles is, When should server roles be split across multiple physical machines? With few exceptions, there is not a rule that says that server roles should be split across multiple pieces of hardware. However, even for a smaller organization, the need for high availability will drive the need for multiple Exchange 2007 servers. The only server role that can be installed on a clustered mailbox server is the Mailbox role. This means an environment that requires clustering of the Mailbox server role will require the other server roles (Hub Transport and Client Access) to be located on separate physical server.

In a small environment, the Hub Transport and Client Access roles can exist on the same physical server. In a medium-sized environment that requires high availability of the Client Access and Hub Transport servers, two Windows servers could be installed and load-balanced. Both of those servers could then host the Client Access and Hub Transport server roles.

What are some other reasons multiple Exchange servers might be required? The justification for additional hardware will be different from one organization to the next and will often depend on the organization's size, but here are a few:

• Server load is too great for a single machine. For example, a server supporting 1,000 mailboxes may be using local continuous replication and thus have an IO profile that precludes having additional disk-intensive, processor-intensive, or Active Directory-intensive roles.

• Redundancy in message routing is required and thus multiple servers with the Hub Transport role are required.

• Redundancy when providing Web Services or Internet access to messaging data requires multiple Client Access servers.

• Simplifying server recovery and rebuilds may require placing different server roles on different physical servers.