Planning for Exchange Active Directory Design
Because Exchange Server 2007 uses Active Directory for its underlying directory structure, it is necessary to link Exchange with a unique Active Directory forest.
In many cases, an existing Active Directory forest and domain structure is already in place in organizations considering Exchange 2007 deployment. In these cases, Exchange can be installed on top of the existing AD environment, and no additional AD design decisions need to be made. It is important to note that Exchange 2007 can only be installed in a Windows Server 2003 Active Directory forest. Windows 2000 forests are not supported.
In some cases, an existing AD infrastructure might not be in place, and one needs to be deployed to support Exchange. In these scenarios, design decisions need to be made for the AD structure in which Exchange will be installed. In some specific cases, Exchange may be deployed as part of a separate forest by itself, as illustrated in Figure 18.7. This model is known as the Exchange resource forest model. The Exchange resource forest is often used in an organization with multiple existing AD forests.
In any case, AD should be designed with simplicity in mind. A single-forest, single-domain model, for example, will solve the needs of many organizations. If Exchange itself is all that is required of AD, this type of deployment is the best one to consider.
Figure 18.7 Understanding the Exchange resource forest model.
NOTE: The addition of Exchange 2007 into an Active Directory forest requires an extension of the AD forest's Active Directory schema. Considerations for this factor must be taken into account when deploying Exchange onto an existing AD forest.
Microsoft has gotten serious recently about support for Exchange Server across multiple forests. This was previously an onerous task to set up, but the capability to synchronize between separate Exchange organizations has been simplified through the use of Microsoft Identity Integration Server (MIIS) 2003. MIIS now comes with a series of preconfigured scripts to replicate between Exchange forests, enabling organizations which, for one reason or another, cannot use a common forest to unite the email structure through object replication.
Planning for the Mailbox Server Role
The Mailbox Server role is the central role in an Exchange topology as it is the server that stores the actual mailboxes of the user. Subsequently, mailbox servers are often the most critical for an organization, and are given the most attention.
With the Enterprise version of Exchange, a mailbox server can hold anywhere from 1 to 50 databases on it. Each of the databases is theoretically unlimited in size, although it is wise to keep an individual database limited to 100GB or less for performance and recovery scenarios.
NOTE: In large organizations, a single server or a cluster of servers is often dedicated to individual server roles. That said, a single server can also be assigned other roles, such as the Client Access Server role, in the interest of consolidating the number of servers deployed. The only limitation to this is the Edge Server role, which must exist by itself and cannot be installed on a server that holds other roles.
Planning for the Client Access Server Role
The Client Access Server (CAS) role in Exchange is the role that controls access to mailboxes from all clients that aren't Microsoft Outlook and that don't utilize MAPI connections. It is the component that controls access to mailboxes via the following mechanisms:
- Outlook Web Access (OWA)
- Exchange ActiveSync
- Outlook Anywhere (formerly RPC over HTTP)
- Post Office Protocol (POP3)
- Interactive Mail Access Protocol (IMAP4)
In addition, CAS servers also handle the following two special services in an Exchange topology:
- Autodiscover service—The Autodiscover service allows clients to determine their synchronization settings (such as mailbox server and so forth) by entering in their SMTP address and their credentials. It is supported across standard OWA connections.
- Availability service—The Availability service is the replacement for Free/Busy functionality in Exchange 2000/2003. It is responsible for making a user's calendar availability visible to other users making meeting requests.
NOTE: In addition to providing HTTP access to Exchange data, CASs fulfill an important role in regards to SharePoint. They provide a direct link to SharePoint sites via the Outlook Web Access interface. Indeed, the Exchange 2007 version of OWA does not even include the capability to access public folders, but instead only allows SharePoint access as an alternative. This illustrates Microsoft's continuing drive to replace public folders with SharePoint.
Planning for the Edge Transport Role
The Edge Transport role is new in Exchange 2007 and is a completely new concept. Edge transport servers are standalone, workgroup members that are meant to reside in the DMZ of a firewall. They do not require access to any internal resources, save for a one-way synchronization of specific configuration information from Active Directory via a process called EdgeSync.
Edge transport servers hold a small instance of Active Directory in Application Mode (ADAM), which is used to store specific configuration information, such as the location of hub transport servers within the topology. ADAM is a service that is often known as Active Directory Light, and can be thought of as a scaled-down version of a separate Active Directory forest that runs as a service on a machine.
The Edge Transport role provides spam and virus filtering, as Microsoft has moved the emphasis on this type of protection to incoming and outgoing messages. Essentially, this role is a method in which Microsoft intends to capture some of the market taken by SMTP relay systems and virus scanners. The market has traditionally been dominated by third-party products provided by virus-scanning companies and Unix SendMail hosts.
In large organizations, redundancy can be built into Edge Transport services through simple round-robin DNS or with the use of a third-party load-balancing service between requests sent to the servers.
Planning for the Hub Transport Role
The Hub Transport role is responsible for the distribution of mail messages within an Exchange organization. At least one Hub Transport role must be defined for each Active Directory site that contains a mailbox server.NOTE: The Hub Transport role can be added to a server running any other role, with only two exceptions. It cannot be added to a server that is an edge transport server, and it cannot be added to a server that is part of a cluster node.
Several special considerations exist for hub transport servers, as follow:
- Multiple hub transport servers can be established in a site to provide redundancy and load balancing.
- Exchange 2007 built-in protection features (antivirus and antispam) are not enabled by default on hub transport servers. Instead, they are enabled on edge transport servers. If needed, they can be enabled on a hub transport server by running a Management Shell script.
- Messaging policy and compliance features are enabled on hub transport servers and can be used to add disclaimers, control attachment sizes, encrypt messages, and block specific content.
Planning for the Unified Messaging Role
The Unified Messaging role in Exchange 2007 is a new concept for Exchange technologies. This role allows fax, voicemail, and email to all be integrated into a user's mailbox.
The Unified Messaging role can be installed on multiple servers, although it is recommended that it only be installed when the infrastructure to support it exists in the organization. The Unified Messaging role requires integration with a third-party Telephone Hardware provider. As Exchange 2007 progresses, this role will become more important.
Understanding a Sample Deployment Scenario
A better understanding of Exchange server roles can be achieved by looking at sample deployment scenarios that utilize these roles. For example, Figure 18.8 illustrates a large enterprise deployment of Exchange that takes advantage of all the unique server roles.
In this design, the following key deployment features are illustrated:
- Cluster continuous replication (CCR) clusters of Exchange mailbox servers are distributed between the two main locations.
- Dedicated hub transport servers distribute mail between the two major sites in San Francisco and Zurich.
- Medium-sized sites, such as Kiev and Lisbon, make use of combined mailbox/hub transport server systems.
- Client access servers are set up in the two main sites to provide two Internet presences for OWA and Outlook Anywhere.
- Edge transport servers process inbound and outbound mail in the DMZ locations in San Francisco and Zurich.
- Unified messaging servers exist in the main hub sites and are provided as a service for users in those locations. The servers are directly connected to PBX systems in those locations.
- Smaller sites, such as Minneapolis, Odessa, and Singapore, have their mailboxes hosted in the two hub locations and use the CASs with Outlook Anywhere to access their mailboxes remotely.
Figure 18.8 Examining an enterprise Exchange deployment.
6 TIPS IN 6 MINUTES: INTEGRATING EXCHANGE 2007 AND SHAREPOINT 2007
Tip 1: Enabling incoming email functionality in SharePoint
Tip 2: Working with email-enabled content in SharePoint 2007
Tip 3: Understanding Microsoft Exchange Server 2007
Tip 4: Planning for an Exchange Server 2007 environment
Tip 5: Integrating Exchange 2007 with SharePoint 2007
Tip 6: SharePoint 2007 and Exchange 2007 best practices
|This chapter excerpt from Microsoft SharePoint 2007 Unleashed, by Michael Noel and Colin Spence, is printed with permission from Sams Publishing, Copyright 2007.|
This was first published in July 2007