Understanding Core Exchange Server 2013 Design Plans

This chapter is from the book

Microsoft Exchange Server 2013 Unleashed

Learn More Buy

This chapter is from the book

This chapter is from the book 

Microsoft Exchange Server 2013 Unleashed

Learn More Buy

The fundamental capabilities of Microsoft Exchange Server 2013 are impressive. Improvements to security, reliability, and scalability enhance an already road-tested and stable Exchange Server platform. Along with these impressive credentials comes an equally impressive design task. Proper design of an Exchange Server 2013 platform will do more than practically anything to reduce headaches and support calls in the future. Many complexities of Exchange Server might seem daunting, but with a full understanding of the fundamental components and improvements, the task of designing the Exchange Server 2013 environment becomes manageable.

This chapter focuses specifically on the Exchange Server 2013 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 2013 implementations are outlined and explained. Enterprise Exchange Server design and planning concepts are expanded in Chapter 3, “Architecting an Enterprise-Level Exchange Server 2013 Environment.”

Planning for Exchange Server 2013

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 2013, on the other hand, takes messaging to a whole new level. No longer do organizations require only an email system, but they now require a high level of system availability and resilience and other messaging and unified communications functionality. 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 Server before beginning a design project.

The Evolution of Exchange Server 2013

Exchange Server 2013 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 the 2000 and 2003 versions of the product. Microsoft then followed upon the success of Exchange Server 2003 with some major architectural changes with Exchange Server 2007 and Exchange Server 2010. This latest version, Exchange Server 2013, uses a similar architecture to both Exchange Server 2007 and 2010, but adds further improvements in key areas and simplifies others.

The major areas of improvement in Exchange Server 2013 include many of the concepts and technologies introduced in Exchange Server 2007 and Exchange Server 2010 but expand upon them and include additional improvements. Key areas improved upon in Exchange Server 2013 architecture include the following:

• Simplified and streamlined role architecture—Exchange Server 2013 simplifies the roles that were introduced in Exchange Server 2007 and Exchange Server 2010, collapsing the Transport roles and Unified Messaging roles into the Mailbox and Client Access Server (CAS) roles, simplifying architecture and providing for design options that were previously unavailable, such as the ability to separate CAS and Mailbox servers geographically. In addition, CAS servers are now stateless, which allows them to be used by any type of load balancer.
• Database availability groups (DAGs)—The Exchange Server 2007 concept of Cluster Continuous Replication (CCR) was replaced with a concept called database availability groups in Exchange Server 2010. DAGs, as they are known, remain available in Exchange Server 2013, and allow a copy of an Exchange Server mailbox database to exist in up to 16 locations within an Exchange Server organization.
• Transport and access improvements—All client access continues to be funneled through the CAS role in an organization, which allows for improvements in client access and limited end-user disruption during mailbox moves and maintenance.
• Integrated archiving capabilities—Exchange Server 2013 users and administrators have the ability to archive messages for the purpose of cleaning up a mailbox of old messages, as well as for legal reasons for applying a retention policy on key messages. Users can simply drag and drop messages into their archive folders, or a policy or rule can be set to have messages automatically moved to the archive folder.
• “Access anywhere” improvements—Microsoft has focused a great deal of Exchange Server 2013 development time on new access methods for Exchange Server, including a greatly enhanced Outlook Web App (OWA) that works with Microsoft and a variety of third-party browsers, Microsoft ActiveSync improvements, Unified Messaging built in, and Outlook Anywhere enhancements. Having these multiple access methods greatly increases the design flexibility of Exchange Server because end users can access email via multiple methods.
• Protection and compliance enhancements—Exchange Server 2013 now has antispam and anti-malware protection built in natively, protecting end users from malicious content. Compliance policies can also be more easily created.
• Admin tools improvements and Exchange PowerShell scripting—Introduced as the primary management tool for Exchange Server 2007, Exchange Server 2013 improves upon PowerShell capabilities and adds additional PowerShell applets and functions. The main graphical user interface (GUI) has also been moved to a Metro UI–style Web console that is accessed through the CAS role. Finally, new split permissions models can be created, which allows Active Directory (AD) and Exchange administrators to have completely separate admin models.

It is important to incorporate the concepts of these improvements into any Exchange Server design project because their principles often drive the design process.

Reviewing Exchange Server and Operating System Requirements

Exchange Server 2013 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 Server version

Each requirement must be addressed before Exchange Server 2013 can be deployed.

Reviewing Hardware Requirements

It is important to design Exchange Server hardware to scale out to the user load, which is expected for at least three years from the date of implementation. This helps retain the value of the investment put into Exchange Server. Specific hardware configuration advice is offered in later sections of this book.

Reviewing Operating System (OS) Requirements

Exchange Server 2013 is optimized for installation on Windows Server 2008 R2 with Service Pack 1 (SP1) or Windows Server 2012. These versions of Windows provide the basis for many of the improvements in Exchange Server 2013. The specific compatibility matrix, which indicates compatibility between Exchange Server versions and operating systems, is illustrated inTable 2.1.

Table 2.1. Exchange Server Version Compatibility

Understanding Active Directory Domain Services (AD DS) Requirements

Exchange Server originally maintained its own directory. With the advent of Exchange 2000 Server, however, the directory for Exchange Server was moved to Microsoft Active Directory Domain Services, 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 Server. Exchange Server 2013 uses the same model but requires specific AD functional levels and domain controller specifics to run properly.

Exchange Server 2013, while requiring an AD forest in all deployment scenarios, has certain flexibility when it comes to the type of AD it uses. It also provides for new capabilities to completely separate domain administrative rights from Exchange rights, a new feature that will be well appreciated by those organizations that have those administrative duties separated.

From an AD DS design perspective, it is possible to deploy Exchange Server in the following scenarios:

• Single forest—The simplest and most traditional design for Exchange Server is one where Exchange Server 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 2013 involves the deployment of a dedicated forest exclusively used for Exchange Server itself, and the only user accounts within it are those that serve as a placeholder for a mailbox. These user accounts are not logged on to 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 Server forest. More information on this deployment model can be found in Chapter 4, “Understanding Network Services and Active Directory Domain Controller Placement for Exchange Server 2013.”
• Multiple forests—Different multiple forest models for Exchange Server are presently available, but they do require a greater degree of administration and synchronization. In these models, different Exchange Server organizations live in different forests across an organization. These different Exchange Server 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 Server deployment because you cannot rename a domain that contains an Exchange server and cannot move an Exchange server to another domain.

Outlining Exchange Server Version Requirements

As with previous versions of Exchange Server, there are separate Enterprise and Standard versions of the Exchange Server 2013 product. The Standard Edition supports all Exchange Server 2013 functionality with the exception of the fact that it is limited to no more than five databases on a single server.

Scaling Exchange Server 2013

Exchange 2000 Server 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 and Exchange Server 2010 and their 64-bit architecture allowed for even further scalability and reduced I/O levels. Finally, Exchange Server 2013 and the separation of client traffic to load-balanced client access servers enable the client tier to be much more scalable than with previous versions.

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 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 Server.

Having Exchange Server 2013 Coexist with an 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 Server 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 2013 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 Server implementation are the following:

• Antivirus (though it is important to note that Exchange Server 2013 now has these features built in)
• Backup
• Phone/PBX/Unified Messaging integration
• Fax software
• Archiving software