Post by Alex on Jul 13, 2012 11:29:55 GMT 5.5
OverviewThe Infrastructure Planning and Design (IPD) series provides guidance for Microsoft infrastructure products. The series is a collection of documents that leads the reader through a sequence of core decision points to design an infrastructure for Microsoft products. It also provides a means to validate design decisions with the business to ensure that the solution meets the requirements for both business and infrastructure stakeholders.
The IPD documents are designed to be used by the following IT personnel:
Infrastructure planners and architects who have a firm operational grasp of the technology.
Partners and consultants who design infrastructure solutions.
Business managers who want to understand how the technology decisions being made both support and affect the business.
Infrastructure Planning and Design (IPD) is a series of planning and design guides created to clarify and streamline the planning and design process for Microsoft® infrastructure technologies.
Each guide in the series addresses a unique infrastructure technology or scenario.
These guides include the following topics:
Defining the technical decision flow (flow chart) through the planning process.
Describing the decisions to be made and the commonly available options to consider in making the decisions.
Relating the decisions and options for the business in terms of cost, complexity, and other characteristics.
Framing the decisions in terms of additional questions for the business to ensure a comprehensive understanding of the appropriate business landscape.
The guides in this series are intended to complement and augment Microsoft product documentation. It is assumed that the reader has a basic understanding of the technologies discussed in these guides. It is the intent of these guides to define business requirements, then align those business requirements to product capabilities, and design the appropriate infrastructure.
Purpose
To provide design guidance for an Exchange Server 2010 infrastructure
Overview
Exchange Server 2010 architecture
Exchange Server 2010 infrastructure design process
What Is Exchange Server 2010?
Exchange Server 2010 provides:
A complete end-to-end solution for electronic messaging both within and outside of an organization
A platform for users to exchange both traditional email messages, as well as non-traditional messages such as faxes and voice mail, in a fault-tolerant, distributed environment that is capable of communicating with other messaging systems across the world
Exchange Server 2010 is an enterprise-class messaging system that provides a complete end-to-end solution for electronic messaging both within and outside of an organization. It provides a platform for users to exchange both traditional email messages, as well as non-traditional messages such as faxes and voice mail, in a fault-tolerant, distributed environment that is capable of communicating with other messaging systems across the world.
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 configurations. To develop and implement a successful Exchange Server 2010 architecture, decisions must be made relative to each of these areas that weigh the value of implementing supporting services against the cost of managing and maintaining those services.
The Exchange Server 2010 design flow provides a graphical overview of the steps in designing an Exchange Server 2010 infrastructure.
These steps are:
Define the Business and Technical Requirements
Define the Instances of Exchange Server 2010
Design the Mailbox Server Infrastructure
Design the Client Access Server Infrastructure
Design the Hub Transport Server Infrastructure
Design the Edge Transport Server Infrastructure
Design the Unified Messaging Server Infrastructure
Define the Active Directory® Domain Services Requirements
Step 1: Define the Business and Technical Requirements
Task 1: Identify Business Requirements
The following questions should be asked of the business to determine the scope and the features that will be implemented:
Which of the following capabilities are needed?
Internal email services
External email services
Connectivity for external users
Public folders
Unified Communications (voice mail) services
What portion of the organization is in scope?
For the parts of the organization that are in scope, do any business isolation requirements exist?
Legal isolation
Political environment
Regulatory requirements
Business policy
Does the organization require an operational consolidation?
Does the organization have a requirement for a unified global address list (GAL)?
Are there any business policies that impact messaging usage?
Message size limits
Mailbox size limits
Employee differentiation
Does the organization require internal message hygiene services?
Availability Requirements
Determine if high availability (automated continuous service) is required for:
Mailbox access – access to an individual mailbox
Mailbox access for external users
Internal message flow – email within the organization
External message flow – email outside of the organization
Message hygiene – antimalware and antispam
Voice mail access
Task 2: Identify Technical Requirements
In this task, the technical requirements will need to be identified to align with the business requirements identified in Task 1.
Which forests and domains will leverage messaging services? In Task 1, the scope of the project for the organization was identified. Record which forests and domains will be impacted by this project. This will be used in the next step to help clearly define the number of Exchange Server instances that will be implemented, as well as any additional forest/domain requirements.
What are the physical locations and requirements? Based on the business requirements from Task 1, document all of the physical locations in the organization that are in scope, including:
Network connectivity
Mailbox counts
PBX and voice IP gateway locations
Message Hygiene Requirements
Message hygiene is an important part of an overall antivirus and antimalware solution. Hardware requirements for running hygiene on Exchange server roles must be addressed and are called out in each applicable section in the individual design steps below.
Mailbox servers
Transport servers
Client Access servers
Unified Messaging (UM) servers
Step 2: Define the Instances of Exchange Server 2010
Task 1: Determine Messaging Service Instances
The minimum number of Exchange Server instances for an organization to implement is one. It is sometimes necessary to add additional Exchange Server instances. If any of the following conditions are true, additional instances may be appropriate:
Mergers and acquisitions
Subsidiaries/business unit separation
Regulatory and/or legal requirements
Business requirements in Step 1
There can be only one instance of Exchange Server per Active Directory forest.
Complex Considerations
Some organizations have multiple Active Directory forests and/or external business relationships whose business requirements call for unified messaging and address list consolidation. If there are multiple forests, Exchange can be deployed either as a cross-forest topology with Exchange in each forest and recipients synchronized to present a unified GAL, or as a resource forest topology with an Exchange forest and one or more user account forests (see technet.microsoft.com/en-us/library/bb124734.aspx). In these cases Microsoft recommends that Microsoft Consulting Services or a certified Microsoft partner be contacted to consult on the design.
Task 2: Determine the Host Domain
Determine which Active Directory forest, site, and domain will be used to host this instance of Exchange Server. Exchange Server has no specific requirements relative to forest, site, or domain locations.
Step 3: Design the Mailbox Server Infrastructure
Task 1: Determine Role Placement
Based on the information gathered in Step 1 relative to mailboxes in the organization, determine where the Mailbox servers should be located, along with the corresponding Active Directory site in which the server will reside. Later sections of this guide address the question of how many servers should be placed in each location identified here. Items that affect the decision about where to locate Mailbox servers include:
Administrative and security requirements
Site autonomy
Fault-tolerance dependencies
Task 2: Plan for Capacity
This task will help to determine capacity planning, which is defined as the total number of mailboxes the server can handle at one time. This is different than performance planning, which focuses on ensuring the Mailbox server performs at a certain level given a set number of clients. The Exchange Server product group has developed a tool that helps with the sizing of Mailbox servers and goes into much more detail than is possible in this guide. The Mailbox Server Role Requirements Calculator can be found at msexchangeteam.com/archive/2009/11/09/453117.aspx.
Task 3: Plan for Performance
Performance planning includes identifying what is required from the server to have the server perform at a certain minimum level. The following assumes that the Mailbox server role will be the only Exchange Server role on the server.
Performance planning centers around the number of processor megacycles required for the server. Determine the number of megacycles per user, based on the estimated user profile and message activity, and multiply by the number of users on the server at peak times. The user count should include the passive copy database users because the passive copy might become the active copy at any time. This will result in the total megacycles required for the server. See the Exchange Server 2010 guide for details relative to calculating performance requirements.
Virtualization
Microsoft supports running the Mailbox server role in hardware virtualized environments, as long as the virtual environment is approved by the Windows Server Virtualization Validation Program.
Task 4: Plan for Fault Tolerance
Create a mapping of databases that require fault tolerance along with the locations that will host passive database copies. Ideally, a passive copy will exist in the same physical location as the active database because that location best serves the active users. Additional copies may be placed in the same location or other locations as desired for additional resiliency or disaster recovery.
Now that the number of fault-tolerant passive database copies per location is known, the next activity is to determine which servers will host the database copies. Use the information derived in Task 2 relative to unallocated database space on each server to determine where passive databases can reside. In situations where there is not enough space on existing servers, it will be necessary to implement new servers of the same configuration to handle the additional databases.
Step 4: Design the Client Access Server Infrastructure
Task 1: Determine Role Placement
It is a product requirement that each AD DS site that contains an Exchange Mailbox server must have at least one Client Access server. Start with one Client Access server per AD DS site-hosting Mailbox servers. Additional Client Access servers may be required, based on the remaining tasks in this step.
Internet-Facing Client Access Server Placement
Add at least one Client Access server for each location that will service Internet-based messaging clients. Note that Microsoft does not support Client Access servers that are directly connected to the Internet. All Client Access servers that will host Internet users must be in an AD DS site configured as Internet facing. Typically, these servers are accessed using an intermediate device (a reverse proxy) such as Microsoft Forefront Unified Access Gateway server (See technet.microsoft.com/en-us/library/ee886315.aspx for more details.).
See technet.microsoft.com/en-us/library/bb310763.aspx for more information about how messaging clients connect and communicate with Client Access servers.
Task 2: Plan for Capacity
Client Access servers are stateless devices that connect users to their Mailbox servers. They do not persist user data on disk, therefore storage design is not a constraining factor. Product minimums are appropriate for disk sizing. See www.microsoft.com/exchange/2010/en/us/system-requirements.aspx for more information on Exchange Server 2010 system requirements.
Task 3: Plan for Performance
Performance planning includes identifying what will be implemented in the server to have the server perform at a certain minimum level. The following assumes that the Client Access server role will be the only Exchange Server role on the server. The Client Access server role may also be deployed on servers with other Exchange Server roles (except for the Edge Transport server role), as long as the resource requirements for the additional loads are identified and addressed.
Virtualization
Microsoft supports running the Client Access server role in hardware virtualized environments, as long as the virtual environment is approved by the Windows Server Virtualization Validation Program.
Task 4: Plan for Fault Tolerance
Map the sites where additional servers need to be deployed along with the number of servers that will be required. A single Client Access server deployed in an AD DS site that contains a Mailbox server is considered a single point of failure for that site. Wherever fault tolerance is needed, implement at least two Client Access servers in an array. In sites that have more than one Client Access server for performance requirements, a single additional fault-tolerant server may not be sufficient in a scenario where two or more Client Access servers become unavailable at the same time. Determine the correct number of additional servers that meet the organization’s fault-tolerance requirements.
After the Client Access server array has been created, a network load balancer (dedicated hardware device or Network Load Balancing) must be implemented to route internal domain-joined Outlook client traffic to the Client Access server array instead of individual servers. If this is not done, those clients will connect to the first Client Access server implemented in the site. See technet.microsoft.com/en-us/library/ff625247.aspx for more information on the details and configuration of the Client Access server role design.
Step 5: Design the Hub Transport Server Infrastructure
Task 1: Determine Role Placement
It is a product requirement that each AD DS site that contains a Mailbox server must have at least one Hub Transport server. Start with one Hub Transport server per AD DS site containing Mailbox servers. Additional Hub Transport servers may be required, based on the remaining tasks in this step.
Task 2: Plan for Capacity
Hub Transport servers are responsible for holding messages while in transit to Mailbox servers. To determine the appropriate storage requirements for the Hub Transport server, see the guide for details.
Step 5: Design the Hub Transport Server Infrastructure
Task 3: Plan for Performance
Performance planning for Hub Transport servers involves four areas: CPU, memory, network, and disk storage performance.
The overall messaging traffic that a single Hub Transport server can handle before it becomes a potential bottleneck varies based on the organization’s particular messaging profiles and workloads. It is assumed that the Hub Transport server role will be the only Exchange Server role on the server.
Virtualization
Microsoft supports running the Hub Transport server role in virtualized environments, as long as the virtual environment is approved by the Windows Server Virtualization Validation Program.
Task 4: Plan for Fault Tolerance
Take the business fault-tolerance requirements from Step 1 and map sites where additional servers need to be deployed along with the number of servers that will be required.
A single Hub Transport server deployed in an AD DS site is considered a single point of failure. Wherever fault tolerance is needed within a site, implement at least one additional Hub Transport server to the calculated number required above. By default, multiple hub transport servers are automatically load balanced within sites on the Exchange Server infrastructure. See technet.microsoft.com/en-us/library/ff634392.aspx for more information.
Step 6: Design the Edge Transport Server Infrastructure
Task 1: Determine Role Placement
It is a product requirement that each Edge Transport server be subscribed to a single Active Directory site containing Hub Transport servers. When messages arrive from outside of the organization, the Edge Transport server passes them only to Hub Transport servers in the specific Active Directory site where the edge server is subscribed. Start with one Edge Transport server for the organization. Additional Edge Transport servers may be required, based on the remaining tasks in this step.
Consider the following when determining where to place Edge Transport servers:
Geographical location. Placing Edge Transport servers in physical sites that are widely separated by geography can help control wide area network utilization by allowing the routing of messages through servers that are closer to external users in that geography.
Network connectivity requirements. Select locations that have acceptable external network connectivity such as bandwidth and latency.
Task 2: Plan for Capacity
Ensure that the disks are properly sized for the expected loads. To determine the appropriate storage requirements for the Edge Transport server, see the guide for details.
Task 3: Plan for Performance
Performance planning for Edge Transport servers involves four areas: CPU, memory, network, and disk storage performance.
The overall messaging traffic that a single Edge Transport server can handle before it becomes a potential bottleneck varies based on the organization’s particular messaging profiles and workloads. The Edge Transport server role must be the only Exchange Server role on the server because this role cannot coexist with other Exchange Server roles.
Virtualization
Microsoft supports running the Edge Transport server role in hardware virtualized environments, as long as the virtual environment is approved by the Windows Server Virtualization Validation Program.
Task 4: Plan for Fault Tolerance
Use the business requirements for fault tolerance identified in Step 1, Task 1 to design perimeter fault tolerance. A single Edge Transport server in the organization is considered a single point of failure. Fault tolerance for Edge Transport services requires attention to two areas:
Edge server failure.
If the Edge-connected AD DS site becomes unavailable.
Step 7: Design the Unified Messaging Server Infrastructure
Task 1: Determine Role Placement
Based on the information gathered in Step 1 relative to users in the organization, determine where Unified Messaging (UM) servers should be located. Items that affect the decision about where to locate Mailbox servers include:
Connectivity
Administrative and security requirements
Site autonomy
Fault-tolerance dependencies
Task 2: Plan for Capacity
Because UM servers immediately forward all messages after they are processed to their destination mailboxes via Hub Transport servers, the disk requirements are minimal. When a UM server is unable to communicate with Hub Transport delivery servers, incoming voice messages are held on the UM server until communications with the Hub Transport servers become available. Ensure that there is enough storage to handle this scenario.
Task 3: Plan for Performance
UM servers substantially leverage the processor cores in the server, as transcoding of audio (inbound), as well as voice recognition (for voice mail previews) must be performed. Voice mail preview is particularly processor intensive; each incoming message requires approximately one minute of processor core time.
Virtualization
Microsoft supports running the UM role in virtualized environments.
Task 4: Plan for Fault Tolerance
Use the business requirements for fault tolerance identified in Step 1, Task 1 to design each site requiring fault tolerance. A single UM server for the organization is considered a single point of failure.
Fault tolerance for UM servers requires attention to two areas:
1. UM server failure
2. IP gateway failure
Step 8: Define the Active Directory Domain Services Requirements
The goal of this step is to determine any requirements for Active Directory Domain Services to support an Exchange Server 2010 deployment planned in the previous steps. Exchange Server 2010 has very specific requirements of Active Directory Domain Services that may require the organization to make adjustments to its currently deployed Active Directory Domain Services infrastructure. If these requirements are not met, Exchange Server 2010 cannot be deployed.
Define Active Directory Domain Services Server Requirements
The following server requirements must be met for Exchange Server to function properly in the environment:
Active Directory Forest. The Active Directory forest must be at Windows Server® 2003 forest functionality mode at a minimum.
Active Directory schema master. The domain controller that holds the Active Directory schema operations master role must be Windows Server 2003 with Service Pack 2 at a minimum.
Active Directory domain controllers. Each domain that hosts Exchange servers must have at least one domain controller that is writable. The server must run Windows Server 2003 with Service Pack 2 at a minimum.
Active Directory global catalog servers. Each site that will host Exchange servers will require at least one global catalog server; depending on the activity in the site and the fault tolerance desired, two or more global catalog servers may be required.
The Exchange Server product group recommends planning for the following:
32-bit platforms: 1 global catalog server processor core for every 4 Mailbox server processor cores.
64-bit platforms: 1 global catalog server processor core for every 8 Mailbox server processor cores.
Summary and Conclusion
This guide has focused on summarizing the critical design decisions, activities, and tasks required to enable a successful design of Microsoft Exchange Server 2010. It has addressed the business requirements, technical aspects, and service characteristics to complete a comprehensive review of the decision-making process. When used in conjunction with product documentation, this guide can help organizations confidently plan a Microsoft Exchange Server 2010 implementation.
The IPD documents are designed to be used by the following IT personnel:
Infrastructure planners and architects who have a firm operational grasp of the technology.
Partners and consultants who design infrastructure solutions.
Business managers who want to understand how the technology decisions being made both support and affect the business.
Infrastructure Planning and Design (IPD) is a series of planning and design guides created to clarify and streamline the planning and design process for Microsoft® infrastructure technologies.
Each guide in the series addresses a unique infrastructure technology or scenario.
These guides include the following topics:
Defining the technical decision flow (flow chart) through the planning process.
Describing the decisions to be made and the commonly available options to consider in making the decisions.
Relating the decisions and options for the business in terms of cost, complexity, and other characteristics.
Framing the decisions in terms of additional questions for the business to ensure a comprehensive understanding of the appropriate business landscape.
The guides in this series are intended to complement and augment Microsoft product documentation. It is assumed that the reader has a basic understanding of the technologies discussed in these guides. It is the intent of these guides to define business requirements, then align those business requirements to product capabilities, and design the appropriate infrastructure.
Purpose
To provide design guidance for an Exchange Server 2010 infrastructure
Overview
Exchange Server 2010 architecture
Exchange Server 2010 infrastructure design process
What Is Exchange Server 2010?
Exchange Server 2010 provides:
A complete end-to-end solution for electronic messaging both within and outside of an organization
A platform for users to exchange both traditional email messages, as well as non-traditional messages such as faxes and voice mail, in a fault-tolerant, distributed environment that is capable of communicating with other messaging systems across the world
Exchange Server 2010 is an enterprise-class messaging system that provides a complete end-to-end solution for electronic messaging both within and outside of an organization. It provides a platform for users to exchange both traditional email messages, as well as non-traditional messages such as faxes and voice mail, in a fault-tolerant, distributed environment that is capable of communicating with other messaging systems across the world.
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 configurations. To develop and implement a successful Exchange Server 2010 architecture, decisions must be made relative to each of these areas that weigh the value of implementing supporting services against the cost of managing and maintaining those services.
The Exchange Server 2010 design flow provides a graphical overview of the steps in designing an Exchange Server 2010 infrastructure.
These steps are:
Define the Business and Technical Requirements
Define the Instances of Exchange Server 2010
Design the Mailbox Server Infrastructure
Design the Client Access Server Infrastructure
Design the Hub Transport Server Infrastructure
Design the Edge Transport Server Infrastructure
Design the Unified Messaging Server Infrastructure
Define the Active Directory® Domain Services Requirements
Step 1: Define the Business and Technical Requirements
Task 1: Identify Business Requirements
The following questions should be asked of the business to determine the scope and the features that will be implemented:
Which of the following capabilities are needed?
Internal email services
External email services
Connectivity for external users
Public folders
Unified Communications (voice mail) services
What portion of the organization is in scope?
For the parts of the organization that are in scope, do any business isolation requirements exist?
Legal isolation
Political environment
Regulatory requirements
Business policy
Does the organization require an operational consolidation?
Does the organization have a requirement for a unified global address list (GAL)?
Are there any business policies that impact messaging usage?
Message size limits
Mailbox size limits
Employee differentiation
Does the organization require internal message hygiene services?
Availability Requirements
Determine if high availability (automated continuous service) is required for:
Mailbox access – access to an individual mailbox
Mailbox access for external users
Internal message flow – email within the organization
External message flow – email outside of the organization
Message hygiene – antimalware and antispam
Voice mail access
Task 2: Identify Technical Requirements
In this task, the technical requirements will need to be identified to align with the business requirements identified in Task 1.
Which forests and domains will leverage messaging services? In Task 1, the scope of the project for the organization was identified. Record which forests and domains will be impacted by this project. This will be used in the next step to help clearly define the number of Exchange Server instances that will be implemented, as well as any additional forest/domain requirements.
What are the physical locations and requirements? Based on the business requirements from Task 1, document all of the physical locations in the organization that are in scope, including:
Network connectivity
Mailbox counts
PBX and voice IP gateway locations
Message Hygiene Requirements
Message hygiene is an important part of an overall antivirus and antimalware solution. Hardware requirements for running hygiene on Exchange server roles must be addressed and are called out in each applicable section in the individual design steps below.
Mailbox servers
Transport servers
Client Access servers
Unified Messaging (UM) servers
Step 2: Define the Instances of Exchange Server 2010
Task 1: Determine Messaging Service Instances
The minimum number of Exchange Server instances for an organization to implement is one. It is sometimes necessary to add additional Exchange Server instances. If any of the following conditions are true, additional instances may be appropriate:
Mergers and acquisitions
Subsidiaries/business unit separation
Regulatory and/or legal requirements
Business requirements in Step 1
There can be only one instance of Exchange Server per Active Directory forest.
Complex Considerations
Some organizations have multiple Active Directory forests and/or external business relationships whose business requirements call for unified messaging and address list consolidation. If there are multiple forests, Exchange can be deployed either as a cross-forest topology with Exchange in each forest and recipients synchronized to present a unified GAL, or as a resource forest topology with an Exchange forest and one or more user account forests (see technet.microsoft.com/en-us/library/bb124734.aspx). In these cases Microsoft recommends that Microsoft Consulting Services or a certified Microsoft partner be contacted to consult on the design.
Task 2: Determine the Host Domain
Determine which Active Directory forest, site, and domain will be used to host this instance of Exchange Server. Exchange Server has no specific requirements relative to forest, site, or domain locations.
Step 3: Design the Mailbox Server Infrastructure
Task 1: Determine Role Placement
Based on the information gathered in Step 1 relative to mailboxes in the organization, determine where the Mailbox servers should be located, along with the corresponding Active Directory site in which the server will reside. Later sections of this guide address the question of how many servers should be placed in each location identified here. Items that affect the decision about where to locate Mailbox servers include:
Administrative and security requirements
Site autonomy
Fault-tolerance dependencies
Task 2: Plan for Capacity
This task will help to determine capacity planning, which is defined as the total number of mailboxes the server can handle at one time. This is different than performance planning, which focuses on ensuring the Mailbox server performs at a certain level given a set number of clients. The Exchange Server product group has developed a tool that helps with the sizing of Mailbox servers and goes into much more detail than is possible in this guide. The Mailbox Server Role Requirements Calculator can be found at msexchangeteam.com/archive/2009/11/09/453117.aspx.
Task 3: Plan for Performance
Performance planning includes identifying what is required from the server to have the server perform at a certain minimum level. The following assumes that the Mailbox server role will be the only Exchange Server role on the server.
Performance planning centers around the number of processor megacycles required for the server. Determine the number of megacycles per user, based on the estimated user profile and message activity, and multiply by the number of users on the server at peak times. The user count should include the passive copy database users because the passive copy might become the active copy at any time. This will result in the total megacycles required for the server. See the Exchange Server 2010 guide for details relative to calculating performance requirements.
Virtualization
Microsoft supports running the Mailbox server role in hardware virtualized environments, as long as the virtual environment is approved by the Windows Server Virtualization Validation Program.
Task 4: Plan for Fault Tolerance
Create a mapping of databases that require fault tolerance along with the locations that will host passive database copies. Ideally, a passive copy will exist in the same physical location as the active database because that location best serves the active users. Additional copies may be placed in the same location or other locations as desired for additional resiliency or disaster recovery.
Now that the number of fault-tolerant passive database copies per location is known, the next activity is to determine which servers will host the database copies. Use the information derived in Task 2 relative to unallocated database space on each server to determine where passive databases can reside. In situations where there is not enough space on existing servers, it will be necessary to implement new servers of the same configuration to handle the additional databases.
Step 4: Design the Client Access Server Infrastructure
Task 1: Determine Role Placement
It is a product requirement that each AD DS site that contains an Exchange Mailbox server must have at least one Client Access server. Start with one Client Access server per AD DS site-hosting Mailbox servers. Additional Client Access servers may be required, based on the remaining tasks in this step.
Internet-Facing Client Access Server Placement
Add at least one Client Access server for each location that will service Internet-based messaging clients. Note that Microsoft does not support Client Access servers that are directly connected to the Internet. All Client Access servers that will host Internet users must be in an AD DS site configured as Internet facing. Typically, these servers are accessed using an intermediate device (a reverse proxy) such as Microsoft Forefront Unified Access Gateway server (See technet.microsoft.com/en-us/library/ee886315.aspx for more details.).
See technet.microsoft.com/en-us/library/bb310763.aspx for more information about how messaging clients connect and communicate with Client Access servers.
Task 2: Plan for Capacity
Client Access servers are stateless devices that connect users to their Mailbox servers. They do not persist user data on disk, therefore storage design is not a constraining factor. Product minimums are appropriate for disk sizing. See www.microsoft.com/exchange/2010/en/us/system-requirements.aspx for more information on Exchange Server 2010 system requirements.
Task 3: Plan for Performance
Performance planning includes identifying what will be implemented in the server to have the server perform at a certain minimum level. The following assumes that the Client Access server role will be the only Exchange Server role on the server. The Client Access server role may also be deployed on servers with other Exchange Server roles (except for the Edge Transport server role), as long as the resource requirements for the additional loads are identified and addressed.
Virtualization
Microsoft supports running the Client Access server role in hardware virtualized environments, as long as the virtual environment is approved by the Windows Server Virtualization Validation Program.
Task 4: Plan for Fault Tolerance
Map the sites where additional servers need to be deployed along with the number of servers that will be required. A single Client Access server deployed in an AD DS site that contains a Mailbox server is considered a single point of failure for that site. Wherever fault tolerance is needed, implement at least two Client Access servers in an array. In sites that have more than one Client Access server for performance requirements, a single additional fault-tolerant server may not be sufficient in a scenario where two or more Client Access servers become unavailable at the same time. Determine the correct number of additional servers that meet the organization’s fault-tolerance requirements.
After the Client Access server array has been created, a network load balancer (dedicated hardware device or Network Load Balancing) must be implemented to route internal domain-joined Outlook client traffic to the Client Access server array instead of individual servers. If this is not done, those clients will connect to the first Client Access server implemented in the site. See technet.microsoft.com/en-us/library/ff625247.aspx for more information on the details and configuration of the Client Access server role design.
Step 5: Design the Hub Transport Server Infrastructure
Task 1: Determine Role Placement
It is a product requirement that each AD DS site that contains a Mailbox server must have at least one Hub Transport server. Start with one Hub Transport server per AD DS site containing Mailbox servers. Additional Hub Transport servers may be required, based on the remaining tasks in this step.
Task 2: Plan for Capacity
Hub Transport servers are responsible for holding messages while in transit to Mailbox servers. To determine the appropriate storage requirements for the Hub Transport server, see the guide for details.
Step 5: Design the Hub Transport Server Infrastructure
Task 3: Plan for Performance
Performance planning for Hub Transport servers involves four areas: CPU, memory, network, and disk storage performance.
The overall messaging traffic that a single Hub Transport server can handle before it becomes a potential bottleneck varies based on the organization’s particular messaging profiles and workloads. It is assumed that the Hub Transport server role will be the only Exchange Server role on the server.
Virtualization
Microsoft supports running the Hub Transport server role in virtualized environments, as long as the virtual environment is approved by the Windows Server Virtualization Validation Program.
Task 4: Plan for Fault Tolerance
Take the business fault-tolerance requirements from Step 1 and map sites where additional servers need to be deployed along with the number of servers that will be required.
A single Hub Transport server deployed in an AD DS site is considered a single point of failure. Wherever fault tolerance is needed within a site, implement at least one additional Hub Transport server to the calculated number required above. By default, multiple hub transport servers are automatically load balanced within sites on the Exchange Server infrastructure. See technet.microsoft.com/en-us/library/ff634392.aspx for more information.
Step 6: Design the Edge Transport Server Infrastructure
Task 1: Determine Role Placement
It is a product requirement that each Edge Transport server be subscribed to a single Active Directory site containing Hub Transport servers. When messages arrive from outside of the organization, the Edge Transport server passes them only to Hub Transport servers in the specific Active Directory site where the edge server is subscribed. Start with one Edge Transport server for the organization. Additional Edge Transport servers may be required, based on the remaining tasks in this step.
Consider the following when determining where to place Edge Transport servers:
Geographical location. Placing Edge Transport servers in physical sites that are widely separated by geography can help control wide area network utilization by allowing the routing of messages through servers that are closer to external users in that geography.
Network connectivity requirements. Select locations that have acceptable external network connectivity such as bandwidth and latency.
Task 2: Plan for Capacity
Ensure that the disks are properly sized for the expected loads. To determine the appropriate storage requirements for the Edge Transport server, see the guide for details.
Task 3: Plan for Performance
Performance planning for Edge Transport servers involves four areas: CPU, memory, network, and disk storage performance.
The overall messaging traffic that a single Edge Transport server can handle before it becomes a potential bottleneck varies based on the organization’s particular messaging profiles and workloads. The Edge Transport server role must be the only Exchange Server role on the server because this role cannot coexist with other Exchange Server roles.
Virtualization
Microsoft supports running the Edge Transport server role in hardware virtualized environments, as long as the virtual environment is approved by the Windows Server Virtualization Validation Program.
Task 4: Plan for Fault Tolerance
Use the business requirements for fault tolerance identified in Step 1, Task 1 to design perimeter fault tolerance. A single Edge Transport server in the organization is considered a single point of failure. Fault tolerance for Edge Transport services requires attention to two areas:
Edge server failure.
If the Edge-connected AD DS site becomes unavailable.
Step 7: Design the Unified Messaging Server Infrastructure
Task 1: Determine Role Placement
Based on the information gathered in Step 1 relative to users in the organization, determine where Unified Messaging (UM) servers should be located. Items that affect the decision about where to locate Mailbox servers include:
Connectivity
Administrative and security requirements
Site autonomy
Fault-tolerance dependencies
Task 2: Plan for Capacity
Because UM servers immediately forward all messages after they are processed to their destination mailboxes via Hub Transport servers, the disk requirements are minimal. When a UM server is unable to communicate with Hub Transport delivery servers, incoming voice messages are held on the UM server until communications with the Hub Transport servers become available. Ensure that there is enough storage to handle this scenario.
Task 3: Plan for Performance
UM servers substantially leverage the processor cores in the server, as transcoding of audio (inbound), as well as voice recognition (for voice mail previews) must be performed. Voice mail preview is particularly processor intensive; each incoming message requires approximately one minute of processor core time.
Virtualization
Microsoft supports running the UM role in virtualized environments.
Task 4: Plan for Fault Tolerance
Use the business requirements for fault tolerance identified in Step 1, Task 1 to design each site requiring fault tolerance. A single UM server for the organization is considered a single point of failure.
Fault tolerance for UM servers requires attention to two areas:
1. UM server failure
2. IP gateway failure
Step 8: Define the Active Directory Domain Services Requirements
The goal of this step is to determine any requirements for Active Directory Domain Services to support an Exchange Server 2010 deployment planned in the previous steps. Exchange Server 2010 has very specific requirements of Active Directory Domain Services that may require the organization to make adjustments to its currently deployed Active Directory Domain Services infrastructure. If these requirements are not met, Exchange Server 2010 cannot be deployed.
Define Active Directory Domain Services Server Requirements
The following server requirements must be met for Exchange Server to function properly in the environment:
Active Directory Forest. The Active Directory forest must be at Windows Server® 2003 forest functionality mode at a minimum.
Active Directory schema master. The domain controller that holds the Active Directory schema operations master role must be Windows Server 2003 with Service Pack 2 at a minimum.
Active Directory domain controllers. Each domain that hosts Exchange servers must have at least one domain controller that is writable. The server must run Windows Server 2003 with Service Pack 2 at a minimum.
Active Directory global catalog servers. Each site that will host Exchange servers will require at least one global catalog server; depending on the activity in the site and the fault tolerance desired, two or more global catalog servers may be required.
The Exchange Server product group recommends planning for the following:
32-bit platforms: 1 global catalog server processor core for every 4 Mailbox server processor cores.
64-bit platforms: 1 global catalog server processor core for every 8 Mailbox server processor cores.
Summary and Conclusion
This guide has focused on summarizing the critical design decisions, activities, and tasks required to enable a successful design of Microsoft Exchange Server 2010. It has addressed the business requirements, technical aspects, and service characteristics to complete a comprehensive review of the decision-making process. When used in conjunction with product documentation, this guide can help organizations confidently plan a Microsoft Exchange Server 2010 implementation.
