다음을 통해 공유


Exchange 2007 - Planning Roadmap for Upgrade and Coexistence

[이 항목은 진행 중입니다.]

적용 대상: Exchange Server 2010

마지막으로 수정된 항목: 2009-12-04

You can deploy Exchange 2010 in an existing Exchange 2007 organization. This topic provides an overview of the planning considerations and configuration steps that you must take when you want Exchange 2010 to coexist with Exchange 2007.

Existing Exchange Organization Planning

Before you go too far in your planning for Exchange 2010, make sure your current Exchange 2007 organization meets the following requirements. For more information, see the following topics:

Understanding Coexistence

Any organization that upgrades from Exchange 2007 to Exchange 2010 will experience a period of coexistence when parts of the organization still use Exchange 2007 functionality and other parts have completed the upgrade to Exchange 2010.

중요

You can only install more Exchange 2007 servers in your organization if you had an Exchange 2007 server there when the first Exchange 2010 server was installed.

Here are a few things about coexistence that you should be aware of:

  • Management interfaces   In Exchange 2010, you can manage Exchange 2010 servers and mailboxes by using either the Exchange Management Console (EMC) or the Exchange Management Shell. You can also use the EMC to view some attributes on Exchange 2007 servers. For more information, see Exchange 관리 콘솔 상호 운용성.
  • Server role features   The Exchange 2010 server role features that are available to clients in the Exchange organization during the coexistence period depend on the version of the Exchange server where the user's mailbox is stored and the version of the e-mail client application that is used to access Exchange.
    For more information about how server-to-server communication occurs in Exchange 2007, see 전송 파이프라인 이해.
  • Routing groups   A large organization that has many routing groups must plan their routing topology to maintain mail flow during the coexistence period. When you plan for a period of coexistence between Exchange 2010 and Exchange 2007, you need to understand the differences in how each version determines its routing topology. For more information about routing and coexistence, see Exchange 2007 전송에서 업그레이드.

Choosing the order of Active Directory sites for upgrade

When you are ready to begin upgrading your organization to Exchange 2010, you must begin with your servers in the internet accessible Active Directory sites first, and then upgrade your internal Active Directory sites. It is not supported to upgrade an internal Active Directory site before all your Internet-accessible sites have been upgraded. This is because Client Access server to Client Access server proxying is only supported from the newer CAS versions (Exchange 2010) to older CAS versions (Exchange 2007) and not the other way around.

Overview of upgrade steps from Exchange 2007 to Exchange 2010
Exchange 2007에서 Exchange 2010으로의 업그레이드 프로세스

Choosing the order of server roles for upgrade

Within the first Active Directory site or sites you are upgrading, the first Exchange 2010 server role you should install is the Client Access server role. When you are ready to begin your deployment, it is recommended to upgrade a single Active Directory site at a time to Exchange 2010. Depending on the size of your Active Directory site, this might be a single Client Access server computer or a load balanced array of Exchange 2010 Client Access servers. The recommended order to install the Exchange 2010 server roles is the following:

  1. Client Access Server role
  2. Hub Transport Server role
  3. Mailbox Server role
  4. Unified Messaging (UM) Server role
  5. Edge Transport Server role

참고

When upgrading to Exchange 2010, you can't perform an in-place server upgrade on an existing Exchange server

For detailed information about upgrading the above server roles, see the following topics:

Understanding Exchange 2007 and Exchange 2003 Mixed Mode Coexistence

혼합 모드 환경을 업그레이드할 준비가 되면 각 Active Directory 사이트를 개별적으로 업그레이드하십시오. 사용자의 Active Directory 사이트에 Exchange 2007 또는 Exchange 2003만 있는 경우 해당 Active Directory 사이트의 해당 버전을 업그레이드하기 위한 지침을 따르십시오. 예를 들어 Active Directory 사이트 A에 Exchange 2007이 있는 경우 Exchange 2007에 대한 업그레이드 지침을 따르십시오. Active Directory 사이트 B에 Exchange 2003이 설치되어 있는 경우 Exchange 2003에 대한 업그레이드 지침을 따르십시오. Exchange 2003 및 Exchange 2007 버전을 업그레이드하는 방법에 대한 자세한 내용은 Upgrade to Exchange 2010를 참조하십시오.

사용자의 Active Directory 사이트에 Exchange 2003 및 Exchange 2007이 모두 설치되어 있는 경우 Exchange 2003 및 Exchange 2007 모두에 대한 업그레이드 지침을 따르고 둘 모두에 필요한 업그레이드 단계를 수행하십시오. 이 시나리오에서 Exchange 2010으로 업그레이드하는 방법에 대한 자세한 내용은 다음 항목을 참조하십시오.

Administration Differences

EMC(Exchange 관리 콘솔)는 Exchange Server 2010과 Exchange Server 2007에서 모두 사용할 수 있습니다. 다음은 Exchange 2010 또는 Exchange 2007에서 EMC를 사용하여 수행할 수 있는 작업 목록입니다.

  • 새 사서함이나 새 OAB(오프라인 주소록) 등의 개체를 만드는 작업은 대상 개체와 같은 EMC 버전에서만 수행할 수 있습니다. 예를 들어 Exchange 2007 사서함 서버에 사서함을 만드는 작업은 Exchange 2007의 EMC로 수행해야 합니다. 다음 사항이 적용됩니다.

    • Exchange 2007 사서함 데이터베이스를 Exchange 2010의 EMC에서 관리할 수 없지만 이러한 데이터베이스를 볼 수는 있습니다.
    • Exchange 2010의 EMC로는 Exchange 2007 통합 메시징 사서함 사용 여부를 설정할 수 없습니다.
    • Exchange 2010의 EMC로는 Exchange 2007 모바일 장치를 관리할 수 없습니다.
  • 개체를 봐야 하는 작업은 몇 가지 예외를 제외하면 모든 버전의 EMC에서 모든 버전의 Exchange 개체에 대해 수행할 수 있습니다.

    • Exchange 2010 및 Exchange 2007 전송 규칙 개체는 해당 버전의 EMC에서만 볼 수 있습니다.

    • Exchange 2010 및 Exchange 2007 서버는 해당 버전의 EMC에서만 볼 수 있습니다.

    • Exchange 2010의 EMC에 있는 큐 뷰어 도구로는 Exchange 2007 서버에 연결하여 큐 또는 메시지를 볼 수 없습니다.

      참고

      저장소 그룹 등의 Exchange 2007 개체가 더 이상 Exchange 2010에 없는 경우에는 Exchange 2010에서 기능을 인식하지 못하기 때문에 상호 운용성이 예상되거나 제공되지 않습니다.

  • Exchange 2010과 Exchange 2007 사이에서는 메시지 추적 구성 작업을 사용할 수 없습니다. Exchange 2007 서버에서는 Exchange 2007 메시징 추적 도구를 사용하고 Exchange 2010 서버에서는 Exchange 2010 메시징 추적 도구를 사용해야 합니다.

Coexistence with the Client Access Server Role

The Client Access server role can coexist with Exchange 2007 Client Access servers. Before you start upgrading your first Active Directory site, you must install Exchange 2007 Service Pack 2 on all Exchange 2007 Client Access servers within your organization.

Once the first Exchange 2010 Client Access server or Client Access server array has been installed in your organization, the Autodiscover Service on the Exchange 2007 Client Access servers will redirect users with mailboxes on an Exchange 2010 Mailbox server to the appropriate Exchange 2010 Client Access end point.

Installation of Exchange 2010 within your organization requires the creation of a second DNS hostname. When you install your first Exchange 2010 Client Access server in your organization, you will also need to create a new hostname. If your current hostname is https://contoso.com, we recommend creating http://legacy.contoso.com. You will need to install your first Exchange 2010 Client Access server or Client Access server array, copy the appropriate Outlook Web Access, Exchange ActiveSync, POP3, IMAP4, Exchange Web Services, and Autodiscover service settings, and then configure http://legacy.contoso.com to point to your Exchange 2007 Client Access servers and https://contoso.com to point to your Exchange 2010 Client Access server or Client Access server array. You will need the appropriate SSL certificate for both hostnames. We recommend a Subject Alternative Name (SAN) which can support multiple hostnames. For more information, see Exchange 2007 클라이언트 액세스에서 업그레이드.

Coexistence with Exchange ActiveSync

For coexistence with Exchange ActiveSync, you will need to configure a legacy DNS hostname. Users with mailboxes on Exchange 2007 Mailbox servers will be proxied from Exchange 2010 to Exchange 2007.

참고

When moving a user's mailbox from Exchange 2007 to Exchange 2010, some users will be prompted to perform a full synchronization of their mailbox. This is a requirement for many mobile phones and will only occur during the first synchronization of the user's phone after their mailbox is moved.

When a user’s mailbox is on Exchange 2007, they will experience the Exchange 2007 version of EAS during co-existence. That user will get the Exchange 2010 functionality of EAS when their mailbox is moved to Exchange 2010. For more information about coexisting with Exchange ActiveSync, see Exchange 2007 클라이언트 액세스에서 업그레이드.

Coexistence with Outlook Web App

If a user with a mailbox on an Exchange 2007 Mailbox server connects to an Exchange 2010 Client Access server in the same Active Directory site, they will be redirected to an Exchange 2007 Client Access server within that site. If a user with a mailbox on an Exchange 2007 Mailbox server connects to an Exchange 2010 Client Access server in a different Active Directory site and there is no Internet-accessible Client Access server in the destination Active Directory site, they will be proxied to an Exchange 2007 Client Access server within the destination Active Directory site. As with Exchange 2007, if a user accesses an Exchange 2010 Client Access server in an Active Directory site that is different from the one where their mailbox resides and there is an Internet-accessible Client Access server in the Active Directory site that contains the user's mailbox, then the user will be redirected to the Client Access server in the destination Active Directory site. When a user’s mailbox is on Exchange 2007, they will experience the Exchange 2007 versions of OWA during co-existence. That user will get the Exchange 2010 functionality of OWA when their mailbox is moved to Exchange 2010.

When upgrading Outlook Web Access, there are three different authentication scenarios that need to be examined.

  • Forms based authentication terminating at an Exchange 2007 Client Access server. In this scenario, the Exchange 2010 Client Access server will redirect the user to the legacy Client Access server and a second sign on won't be required.
  • Third party authentication solution in front of the Exchange 2007 Client Access server. This scenario requires an ISA Server or other authentication solution in front of the Exchange servers. In this situation, users will only be required to authenticate at the authentication solution, which will pass the credentials to any required Exchange 2010 or Exchange 2007 servers.
  • Non-forms based authentication terminating at an Exchange 2007 Client Access server. Outlook Web Access 2010 will redirect the user to a legacy Exchange 2007 Client Access server. Whether the user needs to re-authenticate or not depends on the authentication mechanism used. For example, if Windows Integrated authentication is used, the user will experience a single sign-on with Windows authentication. If HTTP Basic authentication is used, the user will need to authenticate twice.

The upgrade and coexistence steps you must take for Outlook Web Access depend on which authentication scenario you have chosen. For more information about coexisting with Outlook Web Access, see Exchange 2007 클라이언트 액세스에서 업그레이드.

Coexistence with the Hub Transport Server Role

The Hub Transport server role is designed to handle all mail flow for the Exchange organization. It is also responsible for handling Transport Rules, Journaling policies and message delivery. This server is deployed in the Active Directory forest and is required for Exchange 2010 mailboxes to send and receive messages. Messages that are sent to the Internet are relayed by the Hub Transport server to the Edge Transport server or a third-party smart host.

You can add an Exchange 2010 Hub Transport server to an existing Exchange organization after you successfully deploy Exchange 2010 CAS servers. After you introduce Exchange 2010 Hub servers to your Exchange 2007 environment, you still need to maintain your Exchange 2007 Hub servers. Exchange 2010 Mailbox servers can only communicate with Exchange 2010 Hub servers, and Exchange 2007 Mailbox servers can only communicate with Exchange 2007 Hub servers. When a message is sent from a mailbox on an Exchange 2010 Mailbox server to a mailbox that is on an Exchange 2007 Mailbox server, the message is first submitted to the closest Exchange 2010 Hub server in the site. This server then relays the message to an Exchange 2007 Hub server in the same site which finally delivers the message to the Exchange 2007 Mailbox server.

To learn more about introducing Exchange 2010 Hub Transport servers to your Exchange 2007 organization, see Exchange 2007 전송에서 업그레이드.

Coexistence with the Mailbox Server Role

The Mailbox server role can coexist with Exchange 2007 mailbox servers. If you move a mailbox from Exchange 2007 to Exchange 2010, and the mailbox is part of an e-mail address policy, the e-mail addresses for that mailbox is automatically updated based on the configuration of the e-mail address policy. If the mailbox had a primary SMTP address that differs from the e-mail address that is enforced by the e-mail address policy, that SMTP address becomes a secondary SMTP address and the e-mail address generated by the e-mail address policy becomes the primary SMTP address. For information about how to move mailboxes, see 이동 요청 관리.

You can replicate public folder data between Exchange 2010 and Exchange 2007 public folder databases. For more information on Exchange 2010 and Exchange 2007 public folder coexistence, see 공용 폴더 이해.

Coexistence with the Edge Transport Server Role

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 2007 organization.

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 Active Directory preparation steps when you install the Edge Transport server. The Edge Transport server provides antivirus and anti-spam protection as messages enter the network.

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. For more information on Edge Transport servers and coexistence, Exchange 2007 전송에서 업그레이드.

Coexistence with Unified Messaging

When you install the first Exchange 2010 Unified Messaging Server and add it to an existing Exchange 2007 organization, you must first add the Exchange 2010 Unified Messaging server to an existing Unified Messaging dial plan that contains Exchange 2007 Unified Messaging servers. Then you'll need to configure each IP gateway or IP PBX to send all incoming calls to the Exchange 2010 Unified Messaging servers within the Unified Messaging dial plan and not the Exchange 2007 UM servers.

When an incoming call is received by an Exchange 2010 Unified Messaging server and the Unified Messaging-enabled user's mailbox is located on an Exchange 2010 Mailbox server, the Exchange 2010 Unified Messaging server will process the incoming call. If the user's mailbox is located on an Exchange 2007 Mailbox server, the incoming call will be redirected to an Exchange 2007 Unified Messaging server within the same Unified Messaging dial plan and the incoming call will be processed.

Once all Unified Messaging enabled users mailboxes have been migrated to an Exchange 2010 Mailbox server, the Exchange 2007 Unified Messaging servers can be removed from the Unified Messaging dial plan. For more information, see Exchange 2007 통합 메시징에서 업그레이드.

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:

  • Coexistence with Exchange 2000 server or earlier.
  • Coexistence with Exchange 2003 versions prior to Service Pack 2 (SP2).
  • Installing an older version of Exchange into a newly created Exchange 2010 organization.

For more information on deploying in these topologies, see Deploy Multiple Forest Topologies.