Jaa

Planning Roadmap for New Deployments

  • Artikkeli

 

Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2

Before proceeding with deployment of Microsoft Exchange Server 2010, we recommend that you read this topic to help you prepare your organization for deployment.

Exchange Organization Planning

Before deploying Exchange 2010, your existing infrastructure must meet certain prerequisites. Review the following topics to help ensure that your organization is ready for Exchange 2010:

Exchange 2010 Supported Topologies

Exchange 2010 supports the following topologies:

  • Single forest, multiple Active Directory sites.

  • Multiple forests (resource forest model); multiple Active Directory sites.

  • Single Active Directory site.

Exchange 2010 doesn't support the following topologies:

  • Installing earlier version of Exchange into a newly created Exchange 2010 organization.

    Important

    The addition of earlier versions of Exchange to an Exchange 2010–only organization is not supported.

For more information, see Deploy Multiple Forest Topologies.

Exchange Server 2010 Deployment Assistant

Exchange Server 2010 introduces the Exchange Server Deployment Assistant, or ExDeploy, a new Web-based tool that can help you with your Exchange deployment. ExDeploy asks you a few questions about your current environment and then generates a custom checklist and procedures that help simplify your deployment.

For more information, see Exchange Server Deployment Assistant.

Active Directory Planning

Exchange 2010 uses Active Directory Lightweight Directory Service (AD LDS) to store and share directory information with Microsoft Windows. For more information, see Planning Active Directory.

Network and Name Resolution Planning

Make sure that you correctly register host records for servers that run Exchange 2010 in the Domain Name System (DNS) server for the Active Directory forest. Clients and other servers use DNS as the name resolution service to locate Exchange servers. You need to confirm that name resolution is correctly configured for your environment. For more information, see the following topics:

Hub Transport Server Planning

The Hub Transport server role is a required role in an Exchange 2010 organization that provides routing within a single organizational network by using Active Directory sites. Deployed inside the Active Directory forest, computers that have the Hub Transport server role installed handle all mail flow inside the organization, apply transport rules, apply journal rules, and deliver messages to recipients' mailboxes. Messages that are sent to the Internet are relayed by the Hub Transport server to the Edge Transport server role that is deployed in the perimeter network. Messages that are received from the Internet are processed by the Edge Transport server before they are relayed to the Hub Transport server. The Hub Transport server role stores all its configuration information in Active Directory.

When you plan to deploy the Hub Transport server role, you should consider the following issues:

  • Topology options   Begin by planning where you will put your Hub Transport servers in the Exchange physical topology. Exchange uses Active Directory sites to route messages; therefore, you must deploy at least one Hub Transport server in each Active Directory site in which you deploy Mailbox servers. For more information about how to plan for placement of the Hub Transport server, see Overview of the Hub Transport Server Role.

  • Server capacity   Planning for server capacity includes determining how you will conduct performance monitoring of the Hub Transport server. Performance monitoring will help you set a performance baseline for your servers. This information will help determine the capacity of your hardware configuration.

  • Transport features   Determine the transport features that you will enable at the Hub Transport server and how they will be configured.

  • Security The Hub Transport server role is deployed inside the Exchange organization. Planning for Hub Transport server security includes delegation of administrative roles and verification that IP connections are only enabled from authorized servers. Additionally, you should verify that no nonessential services are running and that no unnecessary ports are open. For more information, see Deployment Security Checklist

Internet Connectivity for Hub Transport Servers

To complete mail flow configuration for the Exchange organization and to send and receive e-mail to and from the Internet, you must configure Send connectors and Receive connectors that enable at least one Hub Transport server to connect to the Internet. You can configure Internet connectivity for a Hub Transport by using any of the following methods:

  • You can deploy an Edge Transport server and subscribe it to the Exchange organization. This is the recommended deployment method. By default, when you create the Edge Subscription, the required Send connectors are automatically created. You don't have to modify the configuration of the default Receive connector on the Hub Transport server for this scenario. For more information, see Configure Internet Mail Flow Through a Subscribed Edge Transport Server.

  • You can deploy an Edge Transport server without subscribing it to the Exchange organization. In this scenario, you would have to manually configure the Send and Receive connectors on your Edge Transport and Hub Transport servers, and you won't be able to use features like recipient filtering or safelist aggregation because there is no data replication. For more information, see Configure Mail Flow Between an Edge Transport Server and Hub Transport Servers Without Using EdgeSync.

  • You can send and receive Internet e-mail by relaying through Microsoft Exchange Hosted Services or another third-party SMTP gateway server. In this scenario, you have to create a Send connector and a Receive connector between the Hub Transport server and the external SMTP servers that process and route Internet e-mail. For more information, see Configure Internet Mail Flow Through Exchange Hosted Services or an External SMTP Gateway.

  • You can establish Internet mail flow directly through a Hub Transport server. In this scenario, you have to create a Send connector that routes e-mail to the Internet. Also, you have to modify the configuration of the default Receive connector to accept anonymous e-mail submissions. In this scenario, the Exchange 2010 Hub Transport server can be reached directly through the Internet. We don't recommend this topology because it increases security risks by exposing to the Internet the Exchange 2010 server and all roles installed on that server. Instead, we recommend that you implement a perimeter network-based SMTP gateway, such as the Edge Transport server. For more information, see Configure Internet Mail Flow Directly Through a Hub Transport Server.

    Note

    If you choose to establish Internet mail flow directly through your Hub Transport servers, we recommend that you install the anti-spam agents on your Hub Transport servers so that they can provide anti-spam protection for your Exchange organization. For more information, see Enable Anti-Spam Functionality on a Hub Transport Server.

    Important

    If you configure an Internet-facing Hub Transport server, you can't configure a Send connector to attach a particular IP address to messages that are sent from the Hub Transport server. For example, if more than one IP address is assigned to the Hub Transport server, you can't select which IP address is used by a Send connector to relay e-mail to the Internet. If you use an SMTP relay, such as an Edge Transport server, the IP address of that computer is affixed as the message source.

High Availability and Load Balancing for Hub Transport Servers

Exchange 2010 Transport servers feature shadow redundancy, which provides redundancy for messages for the entire time they are in transit. The solution involves a technique similar to the transport dumpster. With shadow redundancy, the deletion of a message from the transport databases is delayed until the transport server verifies that all of the next hops for that message have completed delivery. If any of the next hops fail before reporting back successful delivery, the message is resubmitted for delivery to that next hop.

Shadow redundancy is enabled by default in your Exchange 2010 environment. To learn more about shadow redundancy, see Understanding Shadow Redundancy.

You achieve load balancing for Hub Transport servers when you install more than one Hub Transport server in the same Active Directory site. By default, connections to Hub Transport servers are automatically load balanced if more than one Hub Transport server is deployed in an Active Directory site. If one Hub Transport server is unavailable, the operational Hub Transport servers continue to accept connections. If all Hub Transport servers in an Active Directory site are unavailable, messages are queued until a Hub Transport server becomes available or the messages expire.

Load balancing of outbound connections to remote domains is achieved by specifying more than one Hub Transport server in the same Active Directory site as a source server for the corresponding Send connector. Load balancing doesn't occur when the source servers for a Send connector are located in different Active Directory sites.

Note

If the Hub Transport server is installed on the same hardware as the Mailbox server role, load balancing may not occur. When the Hub Transport server role is on the same hardware as the Mailbox server role, the local server is preferred for all messages that are sent by users who have mailboxes on that server. Therefore, in this scenario, true load balancing does not occur.

Network Load Balancing (NLB) can be used to provide high availability in the following scenarios:

  • Load balancing of inbound SMTP connections for POP and IMAP client connections to the default Receive connector named "Client <Server Name>" that is created only on Hub Transport servers.

  • Load balancing of inbound SMTP connections for applications that submit e-mail to the Exchange organization.

NLB should not be used to distribute connections for internal routing between Hub Transport servers.

For more information about how to configure Network Load Balancing, see the Network Load Balancing Technical Reference.

Edge Transport Server Planning

The Edge Transport server role is designed to provide improved anti-spam protection for the Exchange organization. The Edge Transport server also applies policies to messages in transport between organizations. This server role is deployed in the perimeter network and outside the Active Directory forest. Edge Transport servers don't have access to Active Directory for configuration and recipient information as do the other Exchange 2010 server roles. The Edge Transport server uses the Active Directory Lightweight Directory Service (AD LDS) to store configuration and recipient information.

You can add an Edge Transport server to an existing Exchange organization making any organizational changes. You don't have to perform any Active Directory preparation steps when you install the Edge Transport server.

When an Edge Transport server is deployed to support an Exchange organization that has not yet deployed Exchange 2010, a limited set of features are available. You can't create an Edge Subscription in this scenario. Therefore, you can't use the Recipient Lookup or safelist aggregation features until you have deployed Exchange 2010 in your organization.

When you're planning to deploy Edge Transport servers, you should consider the following issues:

  • Server Capacity   Planning for server capacity includes planning to conduct performance monitoring of the Edge Transport server. Performance monitoring will help you understand how hard the server is working. This information will determine the capacity of your current hardware configuration.

  • Transport Features   The Edge Transport server can provide anti-spam protection at the edge of the network. As part of your planning process, you should determine the anti-spam features that you will enable at the Edge Transport server and how they will be configured.

  • Security The Edge Transport server role is designed to have a minimal attack surface. Therefore, it's important to correctly secure and manage both the physical access and network access to the server. Planning for security will help you make sure that IP connections are only enabled from authorized servers and from authorized users. For more information, see the Deployment Security Checklist.

    The recommended practice is to put the Edge Transport server within a perimeter network. To make sure that the server can send and receive e-mail and receive recipient and configuration data updates from the Microsoft Exchange EdgeSync service, you must allow communication through the ports that are listed in the following table.

    Communication port settings for Edge Transport servers

    Network interface Open port Protocol Note

    Inbound from and outbound to the Internet

    25/TCP

    SMTP

    This port must be open for mail flow to and from the Internet.

    Inbound from and outbound to the internal network

    25/TCP

    SMTP

    This port must be open for mail flow to and from the Exchange organization.

    Local only

    50389/TCP

    LDAP

    This port is used to make a local connection to AD LDS.

    Inbound from the internal network

    50636/TCP

    Secure LDAP

    This port must be open for EdgeSync synchronization.

    Inbound from the internal network

    3389/TCP

    RDP

    Opening this port is optional. It provides more flexibility in managing the Edge Transport servers from inside the internal network by letting you use a remote desktop connection to manage the Edge Transport server.

    Note

    The Edge Transport server role uses non-standard LDAP ports. The ports that are specified in this topic are the LDAP communication ports that are configured when the Edge Transport server role is installed. For more information, see Modify AD LDS Configuration.

  • EdgeSync You can create an Edge Subscription to subscribe the Edge Transport server to the Exchange organization. When you create an Edge Subscription, recipient and configuration data is replicated from Active Directory to AD LDS. You subscribe an Edge Transport server to an Active Directory site. Then the Microsoft Exchange EdgeSync service that is running on the Hub Transport servers in that site periodically updates AD LDS by synchronizing data from Active Directory. The Edge Subscription process automatically provisions the Send connectors that are required to enable mail flow from the Exchange organization to the Internet through an Edge Transport server. If you're using the recipient lookup or safelist aggregation features on the Edge Transport server, you must subscribe the Edge Transport server to the organization.

Configuring DNS Settings for the Edge Transport Server Role

The Edge Transport server role is deployed outside the Exchange organization as a stand-alone server in the perimeter network or as a member of a perimeter network Active Directory domain. You must manually configure the correct DNS suffix for the Edge Transport server role before you install Exchange 2010. If a DNS suffix isn't configured, setup will fail.

Because the Edge Transport server is typically deployed in the perimeter network, it has network interfaces that are connected to multiple network segments. Each of these network segments has a unique IP configuration. The network interface that is connected to the external, or public, network segment should be configured to use a public DNS server for name resolution. This enables the server to resolve SMTP domain names to MX resource records and route mail to the Internet.

The network interface that is connected to the internal, or private, network segment should be configured to use a DNS server in the perimeter network that can resolve the names of the Hub Transport servers in your organization, or should have a Hosts file available. The Edge Transport servers and the Hub Transport servers must be able to use DNS host resolution to locate each other.

To enable name resolution of Hub Transport servers by Edge Transport servers, use one of the following methods:

  • Manually create A resource records for Hub Transport servers in a forward lookup zone on the DNS server that's configured on the internal network adapter of the Edge Transport server.

  • Edit the Hosts file on the Edge Transport server to include the Host records for the Hub Transport servers. The Hosts file is a local text file in the same format as the 4.3 Berkeley Software Distribution (BSD) UNIX /etc/hosts file. This file maps host names to IP addresses, and the file is stored in the \%Systemroot%\System32\Drivers\Etc folder.

To enable name resolution of Edge Transport servers by Hub Transport servers, use one of the following methods:

  • Manually create A resource records for Edge Transport servers in a forward lookup zone on the DNS server that's configured on the Hub Transport server.

  • To include the Host records for the Edge Transport servers, edit the Hosts file on the Hub Transport servers that are located in the Active Directory sites to which Edge Transport servers are subscribed.

You must follow these steps to configure DNS settings for the Edge Transport server:

  1. Verify that the DNS server settings for each network interface are correct for the network segment.

  2. Configure the DNS suffix for the Edge Transport server name using the following steps:

    1. Click Start, click Control Panel, and then double-click System to open the System Properties.

    2. Click the Computer Name tab.

    3. Click Change.

    4. On the Computer Name Changes page, click More.

    5. In the Primary DNS suffix of this computer: field, type a DNS domain name and suffix for the Edge Transport server.

    This name can't be changed after the Edge Transport server role is installed.

  3. Configure DNS host name resolution for Edge Transport servers and Hub Transport servers.

Overriding DNS Settings

In your environment, you may want to specify a DNS server to route mail that differs from the DNS server that is configured in the Exchange server's IP properties. To accomplish this, modify the Internal DNS Lookups and External DNS Lookups settings of the transport server's properties. These settings override the settings on the network adapter to route e-mail messages. For more information, see Configure Edge Transport Server Properties.

Mailbox Server Planning

The Exchange 2010 Mailbox server role hosts mailbox databases and provides e-mail storage and advanced scheduling services for information workers. The Mailbox server role can also host a public folder database, which provides a foundation for workflow, document sharing, and other forms of collaboration. Servers on which the Mailbox server role is installed are called Mailbox servers.

Before installation, we recommend that you take the time to plan for your Mailbox server role deployment. You must consider several factors when planning the size of your mailbox databases.

Sizing Databases

The recommended maximum database size for Exchange 2010 is greater than the recommended maximum size in previous versions of Exchange.

When planning for the size of your databases, you should also plan for how you will enforce limits on database size, either at the database level or at the individual mailbox level. For more information about mailbox limits, see the following topics:

Public Folder Planning

Public folders are an optional feature in Exchange 2010. If all client computers in your organization are running Microsoft Office Outlook 2007 or later, public folders are an optional feature. However, if Outlook 2003 clients are in use, public folders are required. In addition, if you're currently using public folders for collecting, organizing, or sharing documents and other information and you want to continue doing so, you can use public folder replication to move your public folder data to Exchange 2010.

For more information about public folders, see Understanding Public Folders.

Client Access Server Planning

The Client Access server role receives all client connections for Exchange 2010. Computer-based clients, such as Microsoft Outlook and Microsoft Entourage, mobile phones, and browser-based clients all connect through the Client Access server role. The Client Access server role provides the following functionality:

  • MAPI access

  • POP3 and IMAP4 access

    Note

    Integrated Windows authentication (formerly called NTLM) isn't supported for POP3 or IMAP4 client connectivity. For more information, see the "Client Access Features" sections in Discontinued Features.

  • Outlook Web App access

  • The Autodiscover Service which configures client computers that are running Outlook 2010, Outlook 2007, Entourage, and other client applications. The Autodiscover service can also configure supported mobile devices.

  • The Availability Service improves information workers’ calendaring and meeting scheduling experience by providing secure, consistent and up-to-date free and busy information to computers running Outlook 2007 and later.

When planning your Exchange 2010 deployment, you must have at least one computer with the Client Access server role installed in every Active Directory site that contains Exchange 2010 mailboxes. You can have multiple computers with the Client Access server role installed within each Active Directory site. To provide external client access, at least one Client Access server within your organization must be Internet-facing.

For more information about namespace planning and Client Access servers, see Understanding Client Access Server Namespaces.

Unified Messaging Server Planning

The Unified Messaging server role is designed to provide Unified Messaging (UM) for Exchange 2010 recipients. UM combines voice messaging, fax, and e-mail messaging into one store that can be accessed from a telephone, a user's computer, and a mobile device. Users can access voice messages, e-mail, and calendar information that are located in their Exchange 2010 mailbox from e-mail clients, such as Outlook and Outlook Web App.

The Unified Messaging server depends on the Client Access server, Hub Transport server and Mailbox server. All voice mail messages that are submitted from a Unified Messaging server for a UM-enabled user are first submitted to an Exchange 2010 Hub Transport server as an SMTP message and then are submitted from a Hub Transport server to the UM-enabled user’s mailbox. For a recipient to use Unified Messaging, they must have an Exchange 2010 mailbox. For details, see Understanding Unified Messaging.

Generally, the simpler the Unified Messaging topology, the easier Unified Messaging is to deploy and maintain. Install as few Unified Messaging servers and create as few Unified Messaging objects in Active Directory as you need to support your business and organizational goals. Large enterprises with complex network and telephony environments, multiple business units, or other complexities will require more planning than smaller organizations with relatively straightforward Unified Messaging needs.

Planning Your UM Deployment

You must understand the different aspects of Exchange 2010 Unified Messaging and each component and feature so that you can plan your Unified Messaging infrastructure and deployment appropriately. For details, see Understanding Unified Messaging Components and Understanding Unified Messaging Features.

The following are some of the areas that you should consider and evaluate when planning for Exchange 2010 in your organization:

  • Your business needs for Unified Messaging

  • Your telephony network and your current voice mail system

  • Your current data network design

  • Your current Active Directory environment

  • The number of users that you will have to support

  • The number of Unified Messaging servers you will need

  • The storage requirements for users

  • The placement of IP gateways, telephony equipment, and Unified Messaging servers

For more information, see Overview of Unified Messaging.

Many deployment options are available for Unified Messaging; each option has several steps in common that are required to create a scalable and highly available system to support large numbers of users. These steps are as follows:

  1. Deploy and configure your telephony components for Unified Messaging.

  2. Verify that you've correctly installed the Exchange 2010 server roles that are required by Unified Messaging.

  3. Install the Unified Messaging server role.

  4. Create and configure the required Unified Messaging Active Directory components including UM dial plans, UM IP gateways, UM hunt groups, and UM mailbox policies.

  5. Perform post-deployment tasks including deploying certificates for mutual TLS, creating UM auto attendants, and configuring faxing.

For details about deploying Unified Messaging, see the following topics:

If you're integrating your Unified Messaging environment with Office Communications Server, there are additional planning considerations. For details, see Understanding Unified Messaging and Communications Server 2007 R2. After you have read Understanding Unified Messaging and Communications Server 2007 R2, details about deploying Unified Messaging and Office Communications Server can be found in the following topics:

Exchange Client Planning

Before you deploy your Exchange 2010 organization, verify that client computers and mobile devices in your organization meet the following requirements.

Requirements Check

All MAPI clients are running a supported version of Outlook, including Microsoft Outlook 2007, Outlook 2003.

[ ]

All Outlook Web App clients are running a supported Web browser. To use the complete set of features available in Outlook Web App, clients can use the following browsers on a computer running Windows XP, Windows 2003, Windows Vista, or Windows 7:

  • Internet Explorer 7 and later versions.

  • Firefox 3.0.1 and later versions.

  • Chrome 3.0.195.27 and later versions.

On a computer running Max OS X, clients can use:

  • Safari 3.1 and later versions.

  • Firefox 3.0.1 and later versions.

On a computer running Linux, clients can use:

  • Firefox 3.0.1 and later versions.

Clients using a Web browser that doesn't support the full feature set will automatically be directed to the light version of Outlook Web App. The light version of Outlook Web App is optimized for accessibility, such as for users who are blind or have low vision. The light version provides fewer features and is faster for some operations. Clients may want to use the light version if they are on a slow connection or using a computer with unusually strict browser security settings. The light version can be used with almost any browser and has the same features across all browsers.

[ ]

All mobile devices are running a supported operating system. Windows Mobile phones that are Direct Push compatible or mobile phones running another operating system that is compatible with Exchange ActiveSync.

[ ]

 © 2010 Microsoft Corporation. All rights reserved.