Microsoft recently revised its guide for planning and designing the infrastructure for Exchange Server 2010 with Service Pack 1 as part of its Solution Accelerators series. The guide is aimed at helping messaging architects understand what critical decisions must be made when implementing the server software.
“As with all enterprise-class solution deployments, Exchange Server 2010 requires proper planning around key critical areas: placement of individual servers and roles, capacity planning, performance planning, fault tolerance, and hardware configuration,” Microsoft explained in the document. “To develop and implement a successful Exchange Server 2010 architecture, decisions must be made relative to each of these areas to weigh the value of implementing supporting services against the cost of managing and maintaining those services.”
Because a one-size-fits-all approach doesn’t work with Exchange implementations, the guide makes some assumptions about the environment in which the software will be implemented. For example, it assumes that an Active Directory Domain Services infrastructure that meets the software’s requirements is either in place or has cleared the planning stage. It’s also aimed at a new implementation of Exchange, not a migration to it. In addition, it assumes its readers have a certain level of knowledge about email and electronic messaging, and experience with Windows Server, Active Directory Domain Services and associated technologies. If the Exchange implementation includes Unified Messaging Services, the reader needs to know about technologies such as Private Branch Exchange (PBX) gateways.
According to Microsoft, using the guide has benefits for both internal and external stakeholders in an organization. For the operators of a business, for example, the document allows an infrastructure to be built that not only meets an organization’s needs precisely, but it does so without wasteful spending. What’s more, it brings the business side of operations into the mix from the beginning to the end of the design process.
Infrastructure stakeholders can also benefit from the recommendations in the guide. They can be assured that they’re receiving authoritative information about the process from the people who made the software it uses. They’re also receiving high-integrity design criteria that, nevertheless, consider product limitations, as well as guidance about making their infrastructure fault-tolerant. Moreover, they can be sure that they’re designing an infrastructure that is sized to meet their business requirements.
External consultants and partners can reap rewards from the infrastructure created with the guidance in the document, too. Benefits include rapid readiness for consulting engagements, planning and design templates to standardize design and peer reviews and a “leave-behind” for pre- and post-sales visits to customer sites.
“Using this guide should result in a design that will be sized, configured, and appropriately placed to deliver a solution for achieving stated business requirements, while considering the performance, capacity, manageability, and fault tolerance of the system,” the document noted.
When planning the infrastructure for an Exchange Server 2010 deployment, Microsoft recommends that designers should first define the goals and scope of the project by identifying the features and functions needed by their organizations. Then they should map the features to the roles of individual Exchange servers. They should take into account both the internal and external messaging capabilities needed from the infrastructure, as well as the high-availability requirements that will be placed on it.
The guide suggests eight steps to be followed when designing the Exchange infrastructure.
Define business and technical requirements. An organization’s decision makers should be polled to assess what’s needed from the messaging system. That information can also be used to define the technical requirements and constraints for the system.Define the instances of Exchange Server 2010. This is the first step in designing the architecture for the infrastructure.Design the mailbox server infrastructure. In this step, the mailbox servers’ roles are designed, including their capacity, performance and fault tolerance.Design the client access server infrastructure. This determines how those servers handle protocols such as MAPI, POP3, IMAP, OWA and ActiveSync.Design the hub transport server infrastructure. This piece of the system handles all routing of messages between all mailboxes in the organization and SMTP messages.Design the edge transport server infrastructure. Since this role isn’t always needed, this step helps a designer determine if this component is needed to provide a more secure external messaging experience.Design the unified messaging server infrastructure. As in the other steps, this one provides tips for determining placement and planning for capacity, performance and fault tolerance.Define the Active Directory Domain Services requirements. Since Exchange Server 2010 has very specific requirements for Active Directory Domain Services, it may be necessary to alter an existing Active Directory deployment to accommodate those requirements.
As detailed as the guide is, there are some aspects of infrastructure design outside its scope. For instance, designing an infrastructure that mixes Exchange versions is outside the document’s coverage. Making decisions on the choice of a messaging system isn’t addressed, either, nor are migrations, upgrades or configuring hardware, such as an IP PBX, that are not part of a Microsoft product.
Windows Management and Scripting 