Understanding Core Exchange Server 2007 Design Plans
This chapter is from the book
This chapter is from the book
This chapter is from the book
IN THIS CHAPTER
- Planning for Exchange Server 2007
- Understanding Active Directory Design Concepts for Exchange Server 2007
- Determining Exchange Server 2007 Placement
- Configuring Exchange Server 2007 for Maximum Performance and Reliability
- Securing and Maintaining an Exchange Server 2007 Implementation
The fundamental capabilities of Microsoft Exchange Server 2007 are impressive. Improvements to security, reliability, and scalability enhance an already road-tested and stable Exchange platform. Along with these impressive credentials comes an equally impressive design task. Proper design of an Exchange Server 2007 platform will do more than practically anything to reduce headaches and support calls in the future. Many complexities of Exchange might seem daunting, but with a proper understanding of the fundamental components and improvements, the task of designing the Exchange Server 2007 environment becomes manageable.
This chapter focuses specifically on the Exchange Server 2007 components required for design. Key decision-making factors influencing design are presented and tied into overall strategy. All critical pieces of information required to design Exchange Server 2007 implementations are outlined and explained. Enterprise Exchange design and planning concepts are expanded in Chapter 4, "Architecting an Enterprise-Level Exchange Environment."
Planning for Exchange Server 2007
Designing Exchange Server used to be a fairly simple task. When an organization needed email and the decision was made to go with Exchange Server, the only real decision to make was how many Exchange servers were needed. Primarily, organizations really needed only email and eschewed any "bells and whistles."
Exchange Server 2007, on the other hand, takes messaging to a whole new level. No longer do organizations require only an email system, but other messaging and unified communications functionality as well. After the productivity capabilities of an enterprise email platform have been demonstrated, the need for more productivity improvements arises. Consequently, it is wise to understand the integral design components of Exchange before beginning a design project.
Outlining Significant Changes in Exchange Server 2007
Exchange Server 2007 is the evolution of a product that has consistently been improving over the years from its roots. Since the Exchange 5.x days, Microsoft has released dramatic improvements with Exchange 2000 Server and later Exchange Server 2003. The latest version takes the functionality and reliability of Exchange to the next level, introducing several major enhancements and improvements.
The major areas of improvement in Exchange Server 2007 have focused on several key areas. The first is in the realm of user access and connectivity. The needs of many organizations have changed and they are no longer content with slow remote access to email and limited functionality when on the road. Consequently, many of the improvements in Exchange focus on various approaches to email access and connectivity. The improvements in this group focus on the following areas:
- "Access anywhere" improvements—Microsoft has focused a great deal of Exchange Server 2007 development time on new access methods for Exchange, including an enhanced Outlook Web Access (OWA) that works with a variety of Microsoft and third-party browsers, Microsoft ActiveSync improvements, new Outlook Voice Access (OVA), unified messaging support, and Outlook Anywhere (formerly known as RPC over HTTP). Having these multiple access methods greatly increases the design flexibility of Exchange, as end users can access email via multiple methods.
- Protection and compliance enhancements—Exchange Server 2007 now includes a variety of antispam, antivirus, and compliance mechanisms to protect the integrity of messaging data.
- Admin tools improvements and Exchange Management Shell scripting—The administrative environment in Exchange 2007 has been completely revamped and improved, and the scripting capabilities have been overhauled. It is now possible to script any administrative command from a command-line script. Indeed, the graphical user interface (GUI) itself sits on top of the scripting engine and simply fires scripts based on the task that an administrator chooses in the GUI. This allows for an unprecedented level of control.
- Local Continuous Replication (LCR) and Cluster Continuous Replication (CCR)—One of the most anticipated improvements to Exchange Server has been the inclusion of Local Continuous Replication (LCR) and Cluster Continuous Replication (CCR). These technologies allow for log shipping functionality for Exchange databases, allowing a replica copy of an Exchange database to be constantly built from new logs generated from the server. This gives administrators the ability to replicate in real time the data from a server to another server in a remote site or locally on the same server.
It is important to incorporate the concepts of these improvements into any Exchange design project because their principles often drive the design process.
Reviewing Exchange and Operating System Requirements
Exchange Server 2007 has some specific requirements, both hardware and software, that must be taken into account when designing. These requirements fall into several categories:
- Hardware
- Operating system
- Active Directory
- Exchange version
Each requirement must be addressed before Exchange Server 2007 can be deployed.
Reviewing Hardware Requirements
It is important to design Exchange hardware to scale out to the user load, which is expected for up to 3 years from the date of implementation. This helps retain the value of the investment put into Exchange. Specific hardware configuration advice is offered in later sections of this chapter.
Reviewing Operating System (OS) Requirements
Exchange Server 2007 is optimized for installation on Windows Server 2003. The increases in security and the fundamental changes to Internet Information Services (IIS) in Windows Server 2003 provide the basis for many of the improvements in Exchange Server 2007. The specific compatibility matrix, which indicates compatibility between Exchange versions and operating systems, is illustrated in Table 3.1.
Table 3.1. Exchange Version Compatibility
|
Version |
Windows NT 4.0 |
Windows 2000 |
Windows 2003 |
|
Exchange 5.5 |
Yes |
Yes |
No |
|
Exchange 2000 |
No |
Yes |
No |
|
Exchange 2003 |
No |
Yes |
Yes |
|
Exchange 2007 |
No |
No |
Yes* |
Understanding Active Directory (AD) Requirements
Exchange originally maintained its own directory. With the advent of Exchange 2000, however, the directory for Exchange was moved to the Microsoft Active Directory, the enterprise directory system for Windows. This gave greater flexibility and consolidated directories, but at the same time increased the complexity and dependencies for Exchange. Exchange Server 2007 uses the same model, with either Windows 2000 Server or Windows Server 2003 AD as its directory component.
Exchange 2007, while requiring an AD forest in all deployment scenarios, has certain flexibility when it comes to the type of AD it uses. It is possible to deploy Exchange in the following scenarios:
- Single forest—The simplest and most traditional design for Exchange is one where Exchange is installed within the same forest used for user accounts. This design also has the least amount of complexity and synchronization concerns to worry about.
- Resource forest—The Resource forest model in Exchange Server 2007 involves the deployment of a dedicated forest exclusively used for Exchange itself, and the only user accounts within it are those that serve as a placeholder for a mailbox. These user accounts are not logged onto by the end users, but rather the end users are given access to them across cross-forest trusts from their particular user forest to the Exchange forest. More information on this deployment model can be found in Chapter 4.
- Multiple forests—Different multiple forest models for Exchange are presently available, but they do require a greater degree of administration and synchronization. In these models, different Exchange organizations live in different forests across an organization. These different Exchange organizations are periodically synchronized to maintain a common Global Address List (GAL). More information on this deployment model can also be found in Chapter 4.
It is important to determine which design model will be chosen before proceeding with an Exchange deployment because it is complex and expensive to change the AD structure of Exchange after it has been deployed.
Outlining Exchange Version Requirements
As with previous versions of Exchange, there are separate Enterprise and Standard versions of the Exchange Server 2007 product. The Standard Edition supports all Exchange Server 2007 functionality with the exception of the following key components:
- Greater than 75-GB mailbox store—Exchange Server 2007 can support only a single database of up to 75GB in size. Pre-Exchange 2003-SP2 Standard Exchange only supported up to 16-GB databases. Organizations with small numbers of users or strict storage limits can use this version of Exchange without problems.
- Multiple mailbox database stores—One of the key features of Exchange Server 2007 is the capability of the server to support multiple databases and storage groups with the Enterprise Edition of the software. Up to 50 storage groups and/or 50 databases per server are supported. This capability is not supported with the Standard Edition of the product.
- Clustering support—Exchange Server 2007 clustering, including traditional Single Copy Clustering (shared storage) and the new Cluster Continuous Replication (CCR), is available only when using the Enterprise Edition of the software. Support for up to an eight-way active-passive cluster on Windows Server 2003 is available. Microsoft requires at least one passive node per cluster.
Scaling Exchange Server 2007
The days of the Exchange server "rabbit farm" are gone where it is no longer necessary to set up multiple Exchange server sites across an organization and watch them grow as usage of mail increases in the organization. Exchange 2000 originally provided the basis for servers that could easily scale out to thousands of users in a single site, if necessary. Exchange Server 2003 further improved the situation by introducing Messaging Application Programming Interface (MAPI) compression and RPC over HTTP. Exchange Server 2007 further improves the situation by improving RPC over HTTP (now called Outlook Anywhere) and allowing Mailbox servers to scale upward through 64-bit OS support.
Site consolidation concepts enable organizations that might have previously deployed Exchange servers in remote locations to have those clients access their mailboxes across wide area network (WAN) links or dial-up connections by using the enhanced Outlook 2003/2007 or OWA clients. This solves the problem that previously existed of having to deploy Exchange servers and global catalog (GC) servers in remote locations, with only a handful of users, and greatly reduces the infrastructure costs of setting up Exchange.
Having Exchange Server 2007 Coexist with an Existing Network Infrastructure
Exchange is built upon a standards-based model, which incorporates many industrywide compatible protocols and services. Internet standards—such as DNS, IMAP, SMTP, LDAP, and POP3—are built in to the product to provide coexistence with existing network infrastructure.
In a design scenario, it is necessary to identify any systems that require access to email data or services. For example, it might be necessary to enable a third-party monitoring application to relay mail off the Simple Mail Transfer Protocol (SMTP) engine of Exchange so that alerts can be sent. Identifying these needs during the design portion of a project is subsequently important.
Identifying Third-Party Product Functionality
Microsoft built specific hooks into Exchange Server 2007 to enable third-party applications to improve upon the built-in functionality provided by the system. For example, built-in support for antivirus scanning, backups, and unified messaging exist right out of the box, although functionality is limited without the addition of third-party software. The most common additions to Exchange implementation are the following:
- Antivirus
- Backup
- Phone/PBX integration
- Fax software