文件名称：配置邮件路由的共存-Exchange2010规划和部署
文件大小：4.86MB
文件格式：PPT
更新时间：2024-05-12 13:23:58
Exchange2010
配置邮件路由的共存 Exchange Server 2010不再使用路由组 所有Exchange Server 2010服务器都位于同一个 Exchange Server路由组中 默认情况下，在第一台集线器传输服务器被安装时，将创建一个到Exchange 2003路由组的路由组连接器 边缘传输服务器的考虑 Purpose: Introduce Overview of Transition Server Roles Time: 3 min Key Points: Use a whiteboard diagram to show how a routing group connector is created when the first Exchange Server 2010 Hub Transport server is deployed in an Exchange Server 2003 organization. Consider extending the diagram to describe what happens as Hub Transport servers replace bridgehead servers across multiple Active Directory sites and routing groups. Because Exchange Server 2010 uses Active Directory sites rather than routing groups to manage routing, replacing bridgehead servers can change the routing topology significantly. Routing Topology Differences Exchange Server 2003 use routing groups to define an Exchange-specific routing topology. Typically, routing groups are used to specify a set of well-connected Exchange servers. Servers in the same routing group can communicate with each other without the use of connectors. Ideally, the routing groups that are defined in your existing environment are based on IP subnets and closely mirror the Active Directory Site configuration. When more than one routing group is defined in an Exchange Server 2003 organization, the administrator must manually create routing group connectors to enable mail flow between Exchange Server 2003 servers that are in different routing groups. The routing group connector must specify a source server and a target server as the connector end points. A routing group connector defines a one-way connection, and a reciprocal connector must be created to establish mail flow in both directions. The source and target servers are the bridgehead servers for the routing group. The bridgehead servers relay e-mail to other routing groups on behalf of other servers in their routing group and receive e-mail from other routing groups for delivery to other servers in their routing group. In Exchange 2010, an administrator doesn't have to define an Exchange-specific routing configuration. Exchange 2010 uses the existing Active Directory site topology to define its routing topology. However, an administrator can make Exchange-specific configuration changes to Active Directory sites and IP site link costs to control mail flow. E-mail that is routed to Exchange servers that are located in different sites must be relayed by Hub Transport servers. Hub Transport servers send e-mail to Hub Transport servers in remote sites by using the intra-organization Send connector. The intra-organization Send connector is an implicit connector that is computed by using Active Directory site and IP site link information. Routing group Connector All Exchange 2010 Hub servers are placed in a single separate routing group with a unique name. To enable mail flow between the Exchange 2010 deployment and your existing Exchange 2003 organization, you need to create a Routing Group connector. This Routing Group connector is created during the setup of your first Exchange 2010 Hub Transport server. Link State Updates in a Coexistence Environment The well-known issue: "504 need to authenticate first" When connecting the Exchange 2010 routing group to the Exchange Server 2003 organization, you must consider the behavior of link state routing. Exchange Server 2003 servers maintain a link state routing table that is updated through communication with the Routing Group master. Each connector that has been created between Exchange Server 2003 routing groups is considered a link. Exchange Server 2003 servers determine how a message is routed inside the organization by using the cost that is assigned to these links. If a particular routing group is inaccessible by using the lowest cost route, the link state table is updated by the routing group master to show the state of that link as down. This data is communicated to every routing group in the Exchange organization. When the data is received, the link state table is updated, and another route is calculated. Link state routing is not used by Exchange 2010 Hub Transport servers. Exchange 2010 can't propagate link state updates, and it does not recalculate routes. Hub Transport servers always try to communicate directly with other Hub Transport servers. When a connection to a site is unavailable, Exchange 2010 uses the IP site link costs that are associated with Active Directory sites to determine the closest site at which to queue the message. This behavior is known as queue at point of failure. The message queue that is generated at the point of failure is put in a retry state. If multiple paths exist between the Exchange 2010 routing group and any Exchange Server 2003 routing group, minor link state updates must be suppressed to make sure that message looping does not occur when a route is recalculated. We recommend that minor link state updates be suppressed for each server in the Exchange Server 2003 organization. When link state updates are suppressed, Exchange Server 2003 servers also queue at point of failure, instead of recalculating the route. Configuration changes, such as the addition of connectors, are still communicated between Exchange Server 2003 servers by using link state. However, to ensure that major links state updates continue to occur, you must make sure that the Exchange 2010 routing group is not the only communication path between Exchange 2003 routing groups. Send and Receive Connectors Exchange Server 2003 uses SMTP virtual server interfaces for each protocol to send and receive messages between Exchange servers. Configuration is required only when you modify the default values or create connectors that are specific to another organization. The Exchange 2010 Hub Transport servers use an implicit connector to route messages between sites. This connector is called the intra-organization Send connector. During installation, explicit Receive connectors are automatically created on each Hub Transport server. One Receive connector is configured to receive SMTP traffic from all sources by listening on port 25. A second Receive connector is configured to receive SMTP traffic from non-MAPI clients by listening on port 587. Explicit Send connectors and Receive connectors are created on Hub Transport servers only when you want to create a connector that sends messages to a specific address space or receives messages from a specific address range. X-EXCH50 Data Exchange Server 2003 uses the proprietary verb X-EXCH50 to transmit information about messages and recipients that cannot be included in the e-mail message. The information is transmitted as the Exch50 binary large object. Exch50 contains data such as spam confidence level, address rewriting information, and other MAPI properties that do not have MIME representation. Because X-EXCH50 is a proprietary Extended Simple Mail Transfer Protocol (ESMTP) verb, Exch50 data cannot be propagated by a non-Exchange server. Exchange 2010 supports a mapping between MAPI and MIME and does not require Exch50 data to reliably transmit message properties. To correctly coexist with Exchange Server 2003, Exchange 2010 servers can propagate the Exch50 data to Exchange Server 2003 servers. On incoming SMTP connections, Exch50-related properties that are used by Exchange 2010 are promoted to Exchange 2010-equivalent properties. Properties that are not used by Exchange 2010 but are used by Exchange Server 2003 are preserved. On outgoing SMTP connections, the Exchange 2010 server can form the Exch50 data by promoting the Exchange 2010 properties and appending them to the preserved Exchange Server 2003 data. Routing group connectors between Exchange 2010 and Exchange Server 2003 are automatically configured to support sending and receiving Exch50 data. If you are connecting Exchange 2010 to an Exchange Server 2003 server in a cross-forest scenario, make sure that the connector permissions allow the routing of Exch50 data. For more information, see Configuring Cross-Forest Connectors. Message Tracking The message tracking schema in Exchange 2010 is significantly different from the message tracking schema in Exchange Server 2003. The events that are logged by Exchange 2010 message tracking do not correspond directly to the message tracking events that are logged by Exchange Server 2003. Messages that are sent and received by Exchange 2010 can only be tracked by Exchange 2010 servers. There is no Microsoft Windows Management Instrumentation (WMI) support in Exchange 2010. Therefore, an Exchange Server 2003 server cannot query for message tracking logs on an Exchange 2010 server. If a message tracking query in Exchange 2010 indicates that the message was transferred to an Exchange Server 2003 server, you must use the Exchange Server 2003 message tracking tool to continue to search for the message. Edge Transport Server Coexistence The Edge Transport server role is designed to provide improved antivirus and 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. The Edge Transport server can be deployed as a smart host and SMTP-relay server for an existing Exchange Server 2003 organization. You can add an Edge Transport server to an existing Exchange organization without upgrading the internal Exchange servers or making any organizational changes. Because it deployed outside the Active Directory, you do not have to perform any Active Directory preparation steps when you install the Edge Transport server. If you are using the Exchange Intelligent Message Filter in Exchange Server 2003 to perform anti-spam tasks, you can use the Edge Transport server to provide an additional layer of anti-spam protection. == An Exchange Server 2010 Hub Transport server can subscribe to Exchange 2007 Edge server. An Exchange Server 2007 Mailbox server cannot send or receive messages unless a Hub Transport server also exists in its AD DS site. You can add an Edge Transport server to an existing Exchange organization without upgrading the internal Exchange servers or making any organizational changes. You do not have to perform any AD DS preparation steps when you install the Edge Transport server. If you are using the Exchange Intelligent Message Filter in Exchange Server 2003 to perform anti-spam tasks, you can use the Edge Transport server to provide an additional layer of anti-spam protection. When an Edge Transport server is deployed to support an Exchange organization that has not yet deployed Exchange Server 2010 (Beta), a limited set of features are available. You cannot create an Edge Subscription in this scenario. This means that you cannot use the Recipient Lookup or safelist aggregation features. How to deploy 2010 Edge server to 2003 organization 1. Create a Send connector from the Edge Transport server to the Internet 2. Configure Exchange 2003 to accept messages from the Edge Transport server 3. Create a Send connector from the Edge Transport server to the Exchange 2003 organization 4. Create a Receive connector on the Edge Transport server to accept messages from the Exchange 2003 organization 5. Configure Exchange 2003 to send messages to the Edge Transport server *