• 아티클

Exchange Server 2007

Exchange 2007로 인프라 업그레이드

Kate Follis

 

한 눈에 보기:

  • Exchange 2007의 새로운 기능
  • 업그레이드 준비
  • 역할 기반 배포
  • 메시지 라우팅 토폴로지

Exchange Server 5.5에서 Exchange 2000 Server로의 마이그레이션에 대해 강의한 적이 있는데, 오전 8:30에 시작해서 오후 6:00 무렵에 수업이 끝나게 되어 집에 돌아갈 때는

거의 탈진한 상태가 되곤 했습니다. 디렉터리 리소스 이동, NTDSNoMatch에 대한 많은 혼란, 트러스트되기를 거부하는 우발적인 Windows NT® 4.0 트러스트 등과 관련된 많은 준비 작업이 있었습니다. 시간의 제약으로 Exchange 2000 Server 관리에 대해서는 거의 다루지 못했지만 금요일 밤에 강의실에서 나와 주말 동안 마이그레이션을 끝내려고 했던 소수의 열성적인 수강생들이 변함 없이 있었습니다. 그럴 때마다 주의를 주면서 계획에 더 많은 시간을 투자하라고 권하곤 했지만 그들이 따랐는지는 의문입니다.

Exchange 2000 Server나 Exchange Server 2003에서 Exchange Server 2007로 전환하려는 경우에도 이와 같은 주의가 필요합니다. 즉, 계획에 충분한 시간을 투자해야 합니다. 실제 전환 프로세스는 조직과 현재 배포의 복잡도에 따라 다르지만 여전히 여러 가지 단계가 필요합니다. 규모가 작은 조직에서는 이러한 단계를 단일 프로젝트로 수행할 수 있지만 규모가 큰 조직에서는 점진적으로 서버 역할을 도입하고 일정 기간 동안 함께 사용하는 방식으로 Exchange를 지원하도록 결정할 수 있습니다. 종단 간 프로세스는 전체 전환 기간 동안 메시징 기능과 안정성을 유지하도록 설계되었습니다. 이 기사에서는 Exchange Server 2007로 업그레이드할 때 조직에서 메시지 흐름을 유지 관리하는 데 필요한 필수 단계를 중심으로 설명합니다.

고려 사항

고려해야 할 첫 번째 요구 사항은 64비트 하드웨어에 Exchange Server 2007을 배포해야 한다는 것과 이전 버전의 Exchange에서 곧바로 업그레이드할 수는 없다는 것입니다. 스윙 업그레이드(Swing Upgrade) 방법을 사용하여 기존 메시징 서비스를 Exchange 2007로 마이그레이션해야 합니다. 또한 Exchange 조직이 기본 모드로 운영되고 있어야 Exchange 2007 서버를 추가할 수 있으므로, 조직에서 현재 Exchange 5.5를 사용하고 있으면 Exchange Server 2003으로의 중간 업그레이드를 수행한 후에 Exchange 2007로 이동해야 합니다.

Exchange 2007에는 전환 계획 시 고려해야 할 중요한 변경 내용이 몇 가지 있습니다. 예를 들어 Exchange 2007에 도입된 역할 기반 배포를 사용하면 제공하려는 메시징 서비스를 선택하고 이러한 서비스에 관련된 서버 역할을 배포할 수 있습니다. 전용 하드웨어에 개별적으로 서버 역할을 배포하거나 동일한 실제 서버에 개별 엔터티로 관리되는 여러 개의 역할을 설치할 수 있습니다. 각각에 대한 설명은 "Exchange 2007 서버 역할"을 참조하십시오.

Exchange Server 2007 서버 역할

사서함 서버 사서함 서버 역할은 조직에 메시지 저장소를 제공합니다. Exchange 2007에서는 서버당 최대 50개의 저장소를 지원할 수 있습니다. 이러한 저장소를 50개의 개별 저장소 그룹으로 배포할 수도 있고 단일 저장소 그룹에 최대 50개의 저장소를 만들 수도 있습니다. 클러스터로 배포할 수 있는 역할은 사서함 서버 역할뿐이므로 클러스터링을 사용하려는 경우에는 전용 하드웨어에 사서함 서버를 설치해야 합니다.

클라이언트 액세스 서버 클라이언트 액세스 서버 역할은 프런트 엔드 서버가 제공하는 기능을 대체합니다. 이 역할은 POP3, IMAP4, OWA(Outlook® Web Access), RPC over HTTPS(이제 Outlook Anywhere라고 함), Exchange ActiveSync® 등을 사용하여 Exchange에 액세스하는 클라이언트에 사서함 액세스를 제공합니다.

Hub 전송 서버 이 역할은 Exchange 조직에 SMTP 및 MAPI 메시지 전송 서비스를 제공합니다. 조직 내 사용자가 보내거나 받는 모든 메시지는 Hub 전송 서버가 처리합니다. 이 역할은 조직 내 모든 메시지가 전송 파이프라인의 여러 지점에서 실행되는 에이전트의 서버 기반 규칙이나 저널링 정책을 우회하지 못하도록 하므로 매우 유용합니다.

통합 메시징 서버 이 역할은 사서함에 대한 음성 액세스를 제공합니다. IP/VoIP 게이트웨이나 IP-PBX와 통합되어 메시지와 일정 항목에 대한 전화 액세스를 제공하며 회신을 적을 수 있게 해 줍니다. 이 역할은 Exchange에 새로 추가된 것이므로 이전 버전의 Exchange와 상호 운용할 수 없습니다.

Edge 전송 서버 Edge 전송 서버는 일반적으로 경계 네트워크에 배포되어 Exchange 조직과 인터넷 간의 SMTP 메시지 전송을 제공하고 전송 에이전트를 사용하여 스팸 방지 및 바이러스 백신 처리 기능을 제공합니다. 이제 조직 네트워크 서버와 경계 네트워크 서버 모두에 대해 단일 기술을 표준으로 지정할 수 있습니다. 이 원활한 상호 작용 모델을 통해 관리를 단순화하고 경계 서버를 간편하게 통합할 수 있습니다.

토폴로지 검사

그러면 무엇부터 시작할까요? 현재 상황을 알지 못한다면 어느 방향으로 이동해야 하는지 알기 어렵습니다. 충분한 시간을 두고 현재 환경을 평가하고 토폴로지를 문서화하십시오. 여기에는 Exchange뿐만 아니라 Active Directory® 환경도 포함됩니다. Exchange 2007에서는 링크 상태 라우팅과 라우팅 그룹 및 커넥터에 기반한 토폴로지를 제거하며 조직에서 Active Directory 토폴로지를 설계할 때 투자한 기존 인프라를 활용합니다. 따라서 Active Directory에 모든 Exchange 받는 사람 및 구성 데이터가 저장되고 Active Directory 사이트 구성에서 라우팅 토폴로지가 파생되며 모든 서버 역할이 사이트 인식을 사용하여 다른 서버 역할에서 실행되고 있는 서비스를 검색합니다.

현재 Active Directory 사이트 토폴로지가 기본 실제 네트워크를 정말로 이용하는지, 그리고 모든 Active Directory 사이트가 연결된 서브넷을 가지고 있는지 확인한 다음 기존 Active Directory 사이트와 IP 사이트 링크를 문서화합니다. 모든 Exchange 2003 서버의 실제 위치와 라우팅 그룹 및 라우팅 그룹 커넥터 구조도 문서화합니다.

전환 프로세스에서 가장 까다로운 부분은 라우팅 그룹 기반의 Exchange 라우팅 인프라에서 Active Directory 사이트 기반의 라우팅 인프라로 이동하는 것입니다. 규모가 작은 조직의 경우에는 일반적으로 이 프로세스가 단순하지만 라우팅 그룹이 많은 대규모 조직의 경우에는 Exchange 2003과 Exchange 2007이 공존할 때 중간 단계를 면밀하게 계획해야 합니다. Exchange 2007 사용자가 Exchange 2003 사서함에 보낸 메시지가 낮은 대역폭 연결을 통해 여러 원격 라우팅 그룹을 거치는 것을 원하지는 않을 것이기 때문입니다.

현재 토폴로지에 대해 몇 가지 사항을 가정하는 것으로 시작해 보겠습니다.

  • Exchange 2003 조직이 기본 모드로 실행되고 있습니다.
  • 둘 이상의 라우팅 그룹이 있습니다.
  • 둘 이상의 Active Directory 사이트가 있습니다.

그림 1에서는 Exchange 및 Active Directory 토폴로지를 보여 줍니다. 준비 계획에 포함하는 정보가 자세할수록 더욱 효과적으로 설계할 수 있습니다.

그림 1 Exchange 및 Active Directory 토폴로지

그림 1** Exchange 및 Active Directory 토폴로지 **(더 크게 보려면 이미지를 클릭하십시오.)

Exchange 2007에서 Active Directory를 사용하는 방법

Exchange 2007 서버가 시작되면 해당 서비스에 사이트 속성이 찍힙니다. 이를 통해 이 서버가 제공하는 서비스를 다른 Exchange 2007 서버가 찾을 수 있습니다. Hub 전송 서버만 SMTP를 사용하여 조직 내에서 메시지를 전송할 수 있습니다. 사서함 서버가 포함된 각각의 Active Directory 사이트에는 Hub 전송 서버도 포함되어야 합니다. 또한 사서함 사용자가 MAPI가 아닌 다른 방법을 사용하여 사서함에 액세스하는 경우에는 각 사이트에 클라이언트 액세스 서버도 포함되어야 합니다. 배달을 위해 메시지를 Hub 전송 서버로 전달하면 Hub 전송 서버는 이 메시지를 라우팅할 방법을 결정합니다. Hub 전송 서버와 동일한 Active Directory 사이트에 있는 사서함 서버로 라우팅 방향이 정해지면 Hub 전송 서버는 메시지를 사서함에 배달합니다. 다른 사이트에 있는 사서함 서버로 메시지의 라우팅 방향이 지정되는 경우 Hub 전송 서버는 이 메시지를 원격 사이트에 있는 Hub 전송 서버로 직접 릴레이합니다.

Hub 전송 서버는 Active Directory IP 사이트 링크 비용 정보를 사용하여 받는 사람 사서함이 위치한 Active Directory 사이트에 도달하는 경로 중에서 비용이 가장 낮은 경로를 계산합니다. 경로 선택 알고리즘은 Exchange 2003과 매우 비슷하지만 라우팅 그룹 커넥터 비용 대신에 IP 사이트 링크 비용을 기반으로 합니다. 또한 메시지가 전송 중 각 Hub 전송 서버에 머무르지 않고 원본에서 대상으로 직접 이동합니다. 그렇다면 IP 네트워크를 사용하여 메시지를 전송하면서 굳이 비용이 가장 낮은 경로를 계산하는 이유는 무엇일까요? 여기에는 몇 가지 이유가 있습니다. 하나는 메시지 분기 지연입니다. 두 명 이상의 받는 사람에게 보내는 메시지는 둘 이상의 Active Directory 사이트에 있는 사서함 서버에 배달해야 할 수 있습니다. Exchange 2007에서는 메시지가 첫 번째 Hub 전송 서버에서 분기되거나 분할되는 대신에 라우팅 경로에 있는 포크에 도달해야 분할됩니다. 따라서 메시지가 Active Directory 사이트에서 분기 지점을 나타내는 Hub 전송 서버로 직접 릴레이됩니다. 이러한 동작을 지연된 팬아웃(Delayed Fan-Out)이라고 합니다.

비용이 가장 낮은 경로는 대상에 도달할 수 없는 경우 메시지가 대기할 위치를 결정하는 데도 사용됩니다. 대상 Active Directory 사이트에 있는 Hub 전송 서버에 도달할 수 없는 경우 보내는 Hub 전송 서버는 라우팅 경로에 따라 가장 가까운 다음 Active Directory 사이트에 있는 Hub 전송 서버로 배달하려고 시도합니다. 메시지 배달은 Hub 전송 서버를 사용할 수 있는 Active Directory 사이트에 도달할 때까지 비용이 가장 낮은 경로를 따라 계속됩니다. 최종적으로 받는 사람의 Active Directory 사이트에 이르는 경로를 따라 사용할 수 있는 Hub 전송 서버가 없으면 메시지가 로컬에서 대기합니다. 이 방법을 사용하면 배달 지점에 최대한 가까운 곳에서 메시지가 대기하므로 네트워크 오류 진단이 보다 명확해집니다. 이러한 동작을 장애 지점에서 대기(Queue-at-Point-of-Failure)라고 합니다.

Exchange 2003은 전혀 다른 방식으로 작동합니다. 라우팅 그룹 커넥터에 할당된 비용을 기반으로 하나의 라우팅 그룹에서 다른 라우팅 그룹에 이르는 경로 중 비용이 가장 낮은 경로가 계산됩니다. 라우팅 경로를 따라 각 라우팅 그룹에 있는 브리지헤드 서버가 메시지를 받아서 릴레이합니다. 경로에 있는 다음 커넥터를 사용할 수 없는 경우 대체 경로가 계산됩니다. 다른 Exchange 서버에 연결이 끊겼음을 알려 주는 링크 상태 업데이트 메시지가 Exchange 조직 전반에 걸쳐 전달됩니다. 브리지헤드 서버는 연결이 설정되었음을 나타내는 링크 상태 알림을 받을 때까지 연결이 끊긴 커넥터를 우회하는 라우팅을 시도합니다.

대규모 조직을 전환할 때의 문제는 공존 기간 중에 메일 흐름을 유지 관리하는 것입니다. Exchange 2007이 프로덕션 환경에 도입될 때 이러한 연속성을 달성하기 위해 모든 Exchange 2007 서버는 단일 라우팅 그룹의 구성원이 됩니다. 즉, Exchange 2007 서버가 어느 Active Directory 사이트에 있는지에 관계없이 Exchange 2003은 Exchange 2007 서버가 단일 라우팅 그룹에 속한다고 간주합니다. 따라서 해당 라우팅 그룹과 Exchange 2003 라우팅 그룹 간에 라우팅 그룹 커넥터를 설정할 수 있으므로 Exchange 2003은 메시지를 Exchange 2007로 라우팅하는 방법을 파악할 수 있습니다. 또한 Exchange 2007은 라우팅 그룹 커넥터를 사용하여 메시지를 Exchange 2003에 보내는 방법을 결정합니다. 그러나 Exchange 2007은 항상 다른 Exchange 2007 서버를 통해 메시지를 라우팅하는 것을 선호하며 Exchange 2003 라우팅 그룹의 백본을 통해서는 결코 다른 Exchange 2007 서버에 도달하지 않습니다.

첫 번째 Exchange 2007 서버 도입

Exchange 2003 조직에 첫 번째 Exchange 2007 서버를 설치할 때는 첫 번째 라우팅 그룹 커넥터를 설정할 Exchange 2003 브리지헤드 서버를 선택해야 합니다.

그림 2에서는 첫 번째 Exchange 2007 서버 도입이 조직 토폴로지에 미치는 영향을 보여 줍니다.

그림 2 첫 번째 Exchange 2007 서버 설치

그림 2** 첫 번째 Exchange 2007 서버 설치 **(더 크게 보려면 이미지를 클릭하십시오.)

지금까지는 아주 좋습니다. Exchange 2007이 만든 라우팅 그룹 커넥터의 기본 비용은 1입니다. 메일은 계속해서 Exchange 2003 서버를 통해 평소대로 흐릅니다. Exchange 2003 서버에서 Exchange 2007 서버 사용자에게 메시지를 보내면 아카풀코 라우팅 그룹을 통과합니다. 라우팅 그룹 커넥터가 생성되면 선택한 Exchange 2003 브리지헤드 서버는 자동으로 ExchangeLegacyInterop 유니버설 보안 그룹의 구성원이 되고 Exchange 2007에 전자 메일 메시지를 보내거나 Exchange 2007에서 전자 메일 메시지를 받을 수 있는 올바른 사용 권한을 부여받습니다. Exchange 2007 서버가 커넥터의 원본이나 대상 서버로 지정될 때마다 항상 Exchange 관리 셸에서 New-RoutingGroupConnector를 사용하여 라우팅 그룹 커넥터를 만들어야 합니다. Set-RoutingGroupConnector cmdlet을 사용하여 라우팅 그룹 커넥터의 구성을 수정할 수도 있습니다. 예를 들어 초기 라우팅 그룹 커넥터에 원본 서버와 대상 서버를 추가하여 중복을 제공할 수 있습니다. 자세한 내용은 TechNet Magazine의 이번 호에서 Exchange 관리 셸에 관한 David Strome의 기사를 참조하십시오.

일부 사서함 이동 준비

다음 단계는 Exchange 2003 서버에서 Exchange 2007 서버로 일부 사서함을 이동하는 것입니다. Move-Mailbox cmdlet을 사용하여 이 작업을 수행할 수 있습니다. 그러나 Exchange 2003 서버의 역할을 해제하려면 먼저 Exchange 2007 서버에 송신 커넥터와 수신 커넥터를 만들어 외부 SMTP 주소 공간으로의 라우팅을 처리하기 위해 Exchange 2003 서버에 정의된 SMTP 커넥터를 바꿔야 합니다.

다음 그림에서는 아카풀코 라우팅 그룹의 리소스가 Exchange 2007로 이동했습니다. 아카풀코 라우팅 그룹의 역할을 해제할 수 있지만 이렇게 하려면 지금 다른 라우팅 그룹으로 향하는 라우팅 그룹 커넥터를 설정해야 합니다. 그림 3에서는 마이애미 북부 라우팅 그룹의 브리지헤드 서버에 대한 라우팅 그룹 커넥터를 구성했습니다.

그림 3 라우팅 그룹 커넥터 구성

그림 3** 라우팅 그룹 커넥터 구성 **(더 크게 보려면 이미지를 클릭하십시오.)

계속해서 LA 동부 라우팅 그룹을 Exchange 2007로 전환해 보겠습니다. 이 상황은 라우팅을 유지 관리하기가 약간 까다로운 유형입니다. 그림 4에서는 로스앤젤레스 사이트에 Exchange 2007이 설치되었고 두 번째 라우팅 그룹의 역할이 해제되었지만 추가로 생성된 라우팅 그룹 커넥터는 없습니다.

그림 4 로스앤젤레스 사이트에 설치된 Exchange 2007

그림 4** 로스앤젤레스 사이트에 설치된 Exchange 2007 **(더 크게 보려면 이미지를 클릭하십시오.)

이제 로스앤젤레스 사이트의 Exchange 2007 서버에서 LA 서부 라우팅 그룹의 Exchange 2003 서버로 메시지를 보내면 메시지는 아카풀코, 마이애미 북부, 마이애미 남부의 순서로 릴레이된 다음 최종적으로 LA 서부에 도달합니다. LA 서부 라우팅 그룹의 Exchange 2003 서버에서 로스앤젤레스 사이트의 Exchange 2007 서버로 메시지를 보내면 메시지가 마이애미 남부, 마이애미 북부, 아카풀코의 순서로 릴레이된 다음 최종적으로 로스앤젤레스에 다시 도달하고 맙니다.

이를 피하려면 두 번째 라우팅 그룹 커넥터를 추가해야 합니다. 그림 5에서는 LA 서부에젤레스 사이트에 있는 Exchange 2007 서버로의 라우팅 그룹 커넥터를 추가하는 것을 보여 줍니다. 참고: 라우팅 그룹 커넥터가 너무 많아지지 않도록 하려면 첫 번째 라우팅 그룹 커넥터가 잘 연결된 허브 Active Directory 사이트에서 구성되었는지 확인하십시오.

그림 5 보다 효율적인 라우팅

그림 5** 보다 효율적인 라우팅 **(더 크게 보려면 이미지를 클릭하십시오.)

이렇게 하면 즉시 확인하지 못할 수 있는 문제가 발생합니다. 이제 두 가지 이상의 방법으로 Exchange 2007 라우팅 그룹에 들어가거나 Exchange 2007 라우팅 그룹에서 나올 수 있습니다. Exchange 2007 라우팅 그룹은 링크 상태를 사용하지 않으므로 이제 잠재적 라우팅 루프가 존재합니다. Exchange 2003 서버는 연결이 끊긴 커넥터를 우회하는 대체 경로를 선택할 수도 있지만 Exchange 2007은 항상 비용이 가장 낮은 경로를 선택합니다. 이 문제를 해결하는 방법은 부분 링크 상태 업데이트 메시지를 억제하는 것입니다. 이렇게 하면 연결이 끊긴 커넥터 상태를 알려 주는 링크 상태 메시지는 허용되지만 구성 변경 내용을 알려 주는 링크 상태 메시지는 허용되지 않습니다. 이것이 중요한 이유는 Exchange 2003 서버가 새 라우팅 그룹 커넥터에 대해서는 알아야 하지만 대체 경로 계산을 시도해서는 안 되기 때문입니다. 최종 결과는 Exchange 2003 서버에 Exchange 2007 서버와 같은 장애 지점에서 대기(Queue-at-Point-of-Failure) 동작이 발생하는 것입니다.

그림 6에서는 더 많은 Exchange 2003 리소스가 Exchange 2007로 전환된 것을 보여 줍니다. 링크 상태 업데이트를 억제했으며 논리적 라우팅 경로를 유지 관리하는 라우팅 그룹 커넥터를 주의 깊게 설정했습니다.

그림 6 더 많은 Exchange 2003 리소스를 Exchange 2007로 이동

그림 6** 더 많은 Exchange 2003 리소스를 Exchange 2007로 이동 **(더 크게 보려면 이미지를 클릭하십시오.)

그러나 여전히 문제가 남아 있습니다. 레드먼드와 밴쿠버에 링크 상태 섬(Link-state island)을 만들었습니다. 메일이 마이애미를 통과하여 잘 흐를 수는 있지만 레드먼드와 마이애미의 경우 링크 상태 구성 변경 내용을 알릴 방법이 없습니다. 현재 라우팅 테이블을 유지 관리하려면 레드먼드와 밴쿠버 간에 다른 라우팅 그룹 커넥터를 구성해야 합니다. 이 라우팅 그룹 커넥터의 비용을 충분히 높여서 Exchange 2003이 이 연결에서는 라우팅을 하지 못하도록 차단하면서 링크 상태 구성 변경 내용은 여전히 알려지도록 할 수 있습니다.

신중하게 계획한다면 개별적인 두 개의 Exchange 라우팅 토폴로지를 유지 관리하는 데 따른 문제를 피할 수 있습니다. Exchange 2007 서버만 실행하게 될 때까지 한 번에 하나씩 라우팅 그룹을 전환함으로써 가장 매끄러운 결과를 얻게 됩니다.

지금까지 Exchange 2007의 라우팅 변경 내용과 이러한 변경이 전환에 미치는 영향을 중심으로 살펴봤습니다. Exchange 2007로의 이동을 계획할 때 염두에 두어야 할 다른 고려 사항이 몇 가지 있습니다.

Exchange 2003 프런트 엔드 서버는 Exchange 2007 사서함에 액세스할 수 없습니다. 그러나 Exchange 2007 클라이언트 액세스 서버는 Exchange 2003 사서함에 연결하는 데 아무 문제가 없습니다. Exchange 2007 클라이언트 액세스 서버를 사용할 때는 사서함이 저장된 사서함 서버와 동일한 OWA 버전만 보게 됩니다. 개별 하드웨어에 Exchange 2007을 배포할 경우에는 클라이언트 액세스 서버가 Active Directory 사이트에 도입하는 첫 번째 역할이어야 합니다. 사서함을 Exchange 2007로 이동하기 전에 사서함에 대한 공용 인터넷 액세스를 제공하는 Exchange 2003 프런트 엔드 서버를 Exchange 2007 클라이언트 액세스 서버로 바꿔야 합니다.

사서함 서버 역할이 포함된 각 사이트에는 클라이언트 액세스 서버 역할(MAPI가 아닌 다른 클라이언트가 있는 경우. 그러나 오늘날 OWA를 사용하지 않는 사람은 별로 없을 것입니다.)과 Hub 전송 서버가 필요하다고 언급했습니다. 따라서 서버 역할이 하드웨어를 공유하도록 할 경우에는 역할 선택 항목에 클라이언트 액세스 서버를 포함해야 합니다. 일반적인 설치에는 Hub 전송 서버 역할, 클라이언트 액세스 서버 역할 및 사서함 서버 역할이 포함됩니다. 이 모든 역할은 Exchange의 모든 기능이 작동하도록 하는 데 필요합니다.

전환 프로세스에 대해 고려해야 할 또 다른 사항은 클라이언트 응용 프로그램(Outlook)을 업그레이드하는 시기입니다. 클라이언트를 Outlook 2007로 업그레이드해야만 Exchange 2007 서버의 모든 기능을 제대로 이용할 수 있습니다. 여기에는 향상된 부재 중 메시지 설정과 관리된 사서함 폴더 기능이 포함됩니다.

또한 Edge 전송 서버 역할을 배포할 시기를 결정해야 합니다. 기술적인 측면에서 볼 때 다른 Exchange 2007 서버 역할을 도입하기 전후에 현재 경계 네트워크 SMTP 릴레이 및 스마트 호스트를 Edge 전송 서버로 대체할 수 있습니다. 그러나 Edge 전송 서버를 먼저 배포하면 Exchange 2003이 Edge 전송 서버에 필요한 받는 사람 및 구성 데이터를 Active Directory에서 ADAM(Active Directory Application Mode)으로 복제할 방법이 없기 때문에 전반적인 기능이 제한됩니다.

적어도 하나의 Hub 전송 서버를 설치한 경우에는 경계 네트워크에 Edge 전송 서버를 배포한 다음 Hub 전송 서버가 있는 Active Directory 사이트에 Edge 전송 서버를 가입할 수 있습니다. Hub 전송 서버의 EdgeSync 서비스는 Active Directory에 있는 받는 사람 데이터의 하위 집합을 ADAM에 복제합니다.

이 데이터를 사용하면 Edge 전송 서버가 받는 사람 조회 및 수신 허용 목록 집계를 수행할 수 있으므로 Edge 전송 서버에서 실행되는 스팸 방지 에이전트를 최대한 활용할 수 있습니다. 또한 EdgeSync는 Exchange 조직과 인터넷 사이의 종단 간 메일 흐름에 필요한 송신 커넥터를 만듭니다. 따라서 외부 주소 공간으로의 라우팅을 제공하는 Exchange 2003 SMTP 커넥터를 대체하는 프로세스가 단순해질 수 있습니다.

충분한 시간을 두고 Exchange 2007로의 전환을 계획하면 수월한 경로를 통해 문제 없이 목표를 달성할 수 있음을 알게 됩니다.

Kate Follis는 Exchange 2007 기술 문서 작성 팀의 선임 콘텐츠 게시자이며 Edge 전송 및 Hub 전송 서버 역할을 전문적으로 담당하는 그룹을 이끌고 있습니다. Kate는 Microsoft에 근무하기 전에 수년 동안 Exchange와 Active Directory를 가르치는 MCT(Microsoft Certified Trainer)로 근무했습니다.

© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..