Exchange Server 2003 서비스 팩 1 기반 사이트로 사이트를 통합하는 과정에서 알아야 할 문제

기술 자료 번역 기술 자료 번역
기술 자료: 841659 - 이 문서가 적용되는 제품 보기.
이 문서가 보관되었습니다. "그대로" 제공되었으며, 업데이트가 되지 않을 것입니다.
모두 확대 | 모두 축소

이 페이지에서

요약

중앙 사이트에 Microsoft Exchange Server 2003 서비스 팩 1을 설치한 후에는 원격 사이트에서 중앙 사이트로 Exchange Server 컴퓨터를 이동하는 사이트 통합을 시작할 수 있습니다. 그러나 사이트 통합 중에 여러 가지 문제가 발생할 수 있습니다. 사이트 통합을 시작하기 전에 포리스트의 모든 ADC(Active Directory Connector)를 Exchange Server 2003 서비스 팩 1에 포함된 ADC 버전으로 업그레이드해야 합니다.

또한 원격 사이트와 개체가 이동될 중앙 사이트 간의 Exchange Server 5.5 디렉터리 복제 커넥터 일정을 올바르게 구성하는 것이 좋습니다. Exchange Server 2003 Active Directory Connector 동작과 실행 동안 이 ADC가 사이트에 미치는 영향은 각 네트워크의 여러 가지 변수에 따라 다릅니다.

사이트 간 공용 폴더 이동 후, 관리 그룹 간 이동 후 및 개체 이동 후 많은 문제가 발생할 수 있습니다. 본 문서에 설명된 동작과 문제를 미리 검토하여 이해하면 사이트 간 이동을 준비하는 데 도움이 됩니다.

소개

사이트 통합은 다수의 원격 사이트를 하나의 대형 중앙 사이트나 여러 대형 사이트로 통합하는 프로세스입니다. 중앙 사이트가 구축되어 클라이언트가 Outlook 2003을 실행하기 시작한 후에는 관리자가 원격 사이트의 콘텐츠 통합을 시작할 수 있습니다. 사이트 통합을 통해 주 콘텐츠, 공용 폴더, 사서함 및 디렉터리 개체가 통합되며 오프라인 주소록이나 중앙 사이트에 대한 외부 커넥터 같은 서비스도 통합됩니다. 본 문서에서는 사이트 통합 중 발생할 수 있는 알려진 문제에 대해 간략히 설명하고 문제의 원인도 알아 보며 해결 방법을 제시합니다. 또한 발생할 수 있는 문제를 이해하는 데 도움이 되는 정보를 제공하며 사이트 통합을 완료하는 데 유용한 정보도 제공합니다.

Exchange Server 2003 서비스 팩 1 버전의 Active Directory Connector 설치

사이트 통합을 위해서는 먼저 Microsoft Exchange Server 2003 서비스 팩 1 버전의 ADC가 있어야 합니다. 포리스트의 모든 ADC를 Exchange Server 2003 서비스 팩 1 버전의 ADC로 업그레이드해야 Exchange Server 2003 서비스 팩 1의 Exchange System Manager GUI(그래픽 사용자 인터페이스)에서 사이트 간 이동을 수행할 수 있습니다.

Exchange Server 5.5 디렉터리 복제 커넥터 일정 업데이트(옵션)

사이트 간 이동 과정에서 다양한 디렉터리 변경 사항이 발생할 수 있습니다. 관리자는 원격 사이트와 개체가 이동될 중앙 사이트 간의 Exchange Server 5.5 디렉터리 복제 커넥터 일정을 고려하는 것이 좋습니다. 중앙 사이트에서 통합 중인 원격 사이트로 변경 사항이 빠르게 복제되도록 관리자는 다음과 같이 할 수 있습니다.
  • 원격 사이트와 중앙 사이트 간에 직접 Exchange Server 5.5 복제 커넥터가 설정되어 있는지 확인합니다.
  • ADC가 Active Directory 디렉터리 서비스 변경 사항을 복제하도록 구성되어 있는 복제 커넥터와 복제 브리지헤드가 중앙 사이트의 같은 서버를 사용하는지 확인합니다.
  • Exchange Server 5.5 복제 일정이 항상이나 짧은 간격으로 설정되어 있는지 확인합니다.
이러한 변경 사항은 선택적이지만 이렇게 하는 것이 좋습니다. 디렉터리 복제나 ADC 복제가 지연되면 사이트 간 이동 후 자동화된 정리 프로세스가 완료되는 데 더 오래 걸릴 수 있습니다.

ADC 동작

이동 전의 ADC 동작

공용 폴더의 관리 그룹 간 이동이 완료되기 전에 ADC는 여러 단계의 관리 그룹 간 이동 정리 동작을 완료합니다. 메시지 배달은 ADC 관리 그룹 간 이동 정리가 완료될 때까지 영향을 받습니다.

ADC 정리 동작이 완료되는 시간은 해당 환경, Exchange Server 5.5 사이트 간 복제 및 Active Directory에서 Exchange Server 5.5로의 복제에 따라 다릅니다.

예를 들어 메일 그룹 정리와 스텁 개체 삭제가 12시간마다 실행됩니다. 메일 그룹 정리와 스텁 개체 삭제는 동시에 완료됩니다. 소규모 환경에서는 한 정리 주기나 12시간 내에 이러한 동작이 완료될 수도 있습니다. 대규모 환경에서는 이러한 동작이 완료되기까지 둘 이상의 정리 주기나 24시간 가까이 소요될 수 있습니다. 대규모 환경에서는 다음과 같은 이유로 메일 그룹 정리와 스텁 개체 삭제가 더 오래 걸릴 수 있습니다.
  • Active Directory에서 Exchange Server 5.5로 복제하는 시간
  • Exchange Server 5.5의 사이트 간 복제
정리 속도를 높이려면 연결 동의를 마우스 오른쪽 단추로 누른 다음 지금 복제를 누릅니다. 그러나 속도는 여전히 다음과 같은 이유로 제한됩니다.
  • Active Directory에서 Exchange Server 5.5로 복제하는 시간
  • Exchange Server 5.5의 사이트 간 복제


관리 그룹 간 이동 중에 연결된 Exchange Server 5.5 및 Active Directory 개체에 대한 ADC 동작

사이트 간 이동 중에 스텁 Exchange Server 5.5 개체와 Active Directory 개체의 연결이 끊깁니다. 공용 폴더 이동 도구(PFMigrate)는 ADCGlobalNames의 새 NM_MOVED_CROSS_SITE 플래그를 사용하여 서로 다른 ADCGlobalNames 값을 두 개체에 모두 할당합니다. ADC는 이들 두 개체를 함께 연결하지 않습니다. 따라서 정리가 끝날 때 Active Directory 개체를 삭제하지 않고도 스텁 개체를 삭제할 수 있습니다.

ADC는 ADCGlobalNames가 제거되어 다른 값으로 다시 지정되기 때문에 스텁 Exchange Server 5.5 개체가 Active Directory에 다시 복제되지 못하도록 합니다. ADC가 복제를 막지 않으면 공용 폴더 디렉터리 개체가 Active Directory에 다시 복제되어 결과적으로 개체가 중복되게 됩니다. 또한 ADCGlobalNames가 모든 도메인 컨트롤러에 복제되지 않은 경우에는 사용자가 Active Directory 개체에 다시 연결될 수 있습니다. PFMigrate는 공용 폴더에서 ADCDoNotReplicate를 X.500 프록시 주소로 지정합니다. ADCDoNotReplicate를 이렇게 지정하면 ADC가 이 개체를 Active Directory에 다시 복제하지 않게 됩니다. 사이트 간에 ADCGlobalNames가 복제되지 않기 때문에 사이트 간 비트를 사용하여 이 동작을 중지할 수 없습니다. 따라서 로컬이 아닌 사이트에서 변경된 사항을 복제하는 연결 동의는 사이트 간 비트를 식별할 수 없으며 계속 삭제 사항과 업데이트 사항을 복제하게 됩니다.

ADC 정리 동작

메일 그룹 업데이트


Exchange Server 5.5에서 이전 Exchange Server 5.5 공용 폴더 개체는 메일 그룹에서 제거하고 이동된 공용 폴더는 Active Directory의 메일 그룹에서 업데이트해야 합니다.

도메인 개체는 Active Directory의 가장 기본적인 개체 중 하나입니다. 다른 모든 개체는 도메인 개체에 종속됩니다. 도메인 개체의 DN(고유 이름)은 도메인 DNS 이름의 dc(도메인 구성 요소)로 구성됩니다. 예를 들어 microsoft.com 도메인 개체의 DN은 dc=microsoft,dc=com입니다. 이 개체에 사용되는 objectclass는 domainDNS이고 objectcategory는 DomainDNS입니다.

메일 그룹 구성원이 DN을 기반으로 하고 공용 폴더의 관리 그룹 간 이동 중에 구성원이 변경되지 않기 때문에 Active Directory는 공용 폴더의 올바른 구성원을 포함합니다. ADC는 Exchange Server 5.5에 복제 시 ADCGlobalNames 명령을 사용하여 그룹 구성원과 DN 링크를 조회합니다. ADC는 Active Directory 그룹을 강제로 복제하여 Exchange Server 5.5 메일 그룹을 업데이트할 수 있습니다. 그러나 Exchange Server 5.5 사이트 간에 대기 시간이 있을 수 있습니다. 따라서 사이트에서 메일 그룹이 업데이트될 때 새 개체는 없고 스텁 공용 폴더 개체에 대한 지식만 있을 수 있습니다. 이 문제를 해결하기 위해 ADC는 Exchange Server 5.5 디렉터리 검색 시 새 개체를 찾을 수 없는 경우 이전 개체에 다시 연결할 수 있도록 DN 링크 조회를 수행합니다.

이전 Exchange Server 5.5 공용 폴더가 삭제되어 메일 그룹 정리 후까지 스텁 공용 폴더로 남아 있지 않으면 공용 폴더가 메일 그룹에서 제거되고 메일 그룹 구성원 자격을 잃게 됩니다. 이 문제는 메일 그룹이 Active Directory에 다시 복제되고 사용자가 해당 메일 그룹에서 제거된 경우에 발생할 수 있습니다. 그러나 스텁 공용 폴더가 유지되기 때문에 이러한 메일 그룹을 정리하는 프로세스가 있어야 Exchange Server 5.5 사이트 간에 새로 이동된 공용 폴더 개체가 해당 메일 그룹에 추가되고 결과적으로 스텁 공용 폴더 개체가 제거될 수 있습니다. 이 동작은 다음 두 방법 중 하나로 발생할 수 있습니다.
  • PFMigrate 프로세스가 Active Directory에서 이동된 공용 폴더가 속한 메일 그룹을 모두 처리합니다. 따라서 Active Directory가 올바른 구성원을 Exchange Server 5.5에 다시 복제합니다. 복제된 ObjectVersion 특성은 Active Directory에서 업데이트됩니다.
  • 메일 그룹이 대상 사이트에 없으면 ADC가 자동으로 공용 폴더가 속한 모든 메일 그룹의 복제를 강제할 수 있습니다. PFMigrate는 관리 그룹 간에 이동된 모든 공용 폴더에 대해 X500:ADCDeleteWhenUnlinked 프록시 값을 지정하고 메일 그룹 구성원을 조회합니다. ADC는 프록시 주소가 X500:ADCDeleteWhenUnlinked인 개체를 검색하여 복제를 강제합니다. 메일 그룹이 로컬 사이트에 있으면 새 사이트의 새 공용 폴더에 대해 올바른 구성원 자격이 있는 Active Directory의 그룹을 처리하여 Exchange Server 5.5에 강제로 복제합니다. 이 동작은 미확인 DN 링크를 확인하기 위해 ADC의 디렉터리 정리 단계에 추가되었으며 12시간마다 실행됩니다.



원래 Exchange Server 5.5 사이트의 이전 스텁 개체 제거


X500:ADCDeleteWhenUnlinked 프록시 값은 MemberOf 특성이 비어 있을 때 개체를 삭제해야 함을 나타내기 위해 PFMigrate 프로세스가 개체에 지정합니다. 이는 앞서 설명한 업데이트된 메일 그룹 동작 때문에 개체가 어느 메일 그룹에도 속하지 않음을 의미합니다. 이 동작은 미확인 DN 링크를 확인하기 위해 ADC의 디렉터리 정리 단계에도 추가되었습니다.

Outlook Web Access 및 Outlook의 읽음/읽지 않음 상태

사이트 간 공용 폴더 이동 중에 공용 폴더가 다른 서버로 이동하면 공용 폴더에 있는 메시지의 읽음/읽지 않음 상태가 손실됩니다. 이 동작은 서버 간에 읽음/읽지 않음 상태가 복제되지 않기 때문에 발생합니다. 따라서 사용자가 Outlook Web Access를 사용할 때나 Outlook에서 사이트 간에 이동된 공용 폴더에 액세스할 때 모든 메시지는 읽지 않은 것으로 나타납니다. 이 동작은 사이트 내에서 공용 폴더 복제본을 이동할 때도 발생하며 사이트 간 이동에만 해당되는 문제가 아닙니다.

사이트 간에 이동된 공용 폴더에 대한 액세스

다음과 같은 동작이 발생할 수 있습니다.
  • 이동된 공용 폴더에 대한 액세스가 일시적으로 거부될 수 있습니다.
  • 공용 폴더의 새 홈으로 리디렉션되지 않을 수 있습니다.
  • 새 공용 폴더에 일부 콘텐츠가 없을 수 있습니다.
이 동작은 다음 두 이유 중 하나로 발생할 수 있습니다.
  • 사이트 간에 이동된 공용 폴더에 액세스하는 사용자의 서버에서 복제본 목록이 업데이트되지 않은 경우 사용자는 복제본 목록이 업데이트될 때까지 이전 복제본으로 연결됩니다. 이전 복제본이 삭제된 경우에는 사용자에게 공용 폴더에 대한 액세스 권한이 부여되지 않습니다. 복제본 목록은 사이트 간 이동 후 5분 이내에 업데이트되어야 합니다. 그러나 공용 폴더 복제본을 삭제해야 복제본 목록을 복제할 수 있는 경우에는 복제본 목록이 업데이트될 때까지 사용자가 공용 폴더에 액세스할 수 없습니다.
  • 새 사이트에 모든 콘텐츠가 복제되기 전에 새 사이트에 연결하여 공용 폴더에 액세스하려 했을 수 있습니다.


공용 폴더 접근 허용

새 사이트에 대해 공용 폴더 접근 허용이 설정되어 있지 않으면 공용 폴더에 대한 액세스가 완전하지 않을 수 있습니다. 이 동작은 사이트 간 공용 폴더 이동 전에 공용 폴더의 새 "홈" 사이트에 대해 접근 허용을 구성해야 하기 때문에 발생합니다. 이 동작은 공용 폴더 복제본을 이동할 때도 발생하며 사이트 간 이동에만 해당되는 문제가 아닙니다.

공용 폴더 접근 허용은 클라이언트 프로그램에서 다른 사이트의 서버를 보고 공용 폴더에 액세스하는 기능입니다. 이는 로컬 사이트에 해당 폴더를 복제하는 대신에 수행됩니다. 공용 폴더 접근 허용은 대개 고대역폭 연결이 있는 경우에 사용됩니다.

참고 사서함 이동 단계 중에 원본 사이트와 대상 사이트 모두에서 복제본을 제공하는 지침을 따른 경우에는 공용 폴더 접근 허용이 필요하지 않습니다. 접근 허용은 사서함 이동 전후에 전체적으로 공용 폴더가 이동된 경우에 필요합니다.

알려진 문제: 사이트 간 공용 폴더 이동 후의 동작

공용 폴더에 전자 메일 메시지를 보낼 때 Exchange Server 5.5 사용자와 Exchange Server 2003 사용자에게 미치는 영향

메시지 배달 문제는 관리 그룹 간에 이동하거나 ADC가 Exchange Server 5.5 디렉터리 개체를 정리하는 동안 사용자가 공용 폴더에 전자 메일 메시지를 보낼 때 발생할 수 있습니다.

참고 사이트 간 이동 중에 사용자가 다음과 같은 내용의 오류를 포함하는 NDR(배달 못 함 보고서)을 받을 수 있습니다.
액세스가 거부되었습니다. 0x80070005




받은 편지함 규칙


관리 그룹 간에 공용 폴더를 이동한 후에 FID(폴더 ID)를 기반으로 공용 폴더 간에 메시지를 이동하는 규칙이 제대로 작동하지 않습니다. 다음과 유사한 메시지가 나타날 수 있습니다.
대상 폴더를 찾을 수 없습니다.




전체 주소 목록의 이동된 공용 폴더


관리 그룹 간에 이동된 공용 폴더가 Exchange Server 5.5의 전체 주소 목록에서 사라질 수 있습니다. 이 동작은 새 Exchange Server 5.5 개체가 Active Directory에서 새 사이트로 복제되기 전에 이전 사이트의 원래 Exchange Server 5.5 개체가 숨겨진 경우에 발생할 수 있습니다. Active Directory, Exchange 2000 Server 전체 주소 목록 또는 Exchange Server 2003 전체 주소 목록에서는 관리 그룹 간에 이동된 공용 폴더가 영향을 받지 않습니다.



업무 일지


Exchange Server 5.5 또는 Exchange 2000 Server에 사용되는 공용 폴더가 관리 그룹 간에 이동되면 업무 일지가 제대로 작동하지 않습니다. 이 문제는 LegacyExchangeDN 특성이 변경되기 때문에 발생합니다.

참고 Exchange 2000과 Exchange Server 2003의 공용 폴더에 대한 업무 일지 사용은 지원되지 않으며 Exchange 환경에서 기능 문제와 성능 문제를 유발할 수 있습니다. 사이트 간 이동 후 업무 일지를 다시 구성할 때 업무 일지의 대상을 공용 폴더 대신 사서함으로 변경합니다.



관리 양식


관리 양식은 PFMigrate 스크립트를 통해 사이트 간에 이동되지 않습니다. 관리 양식은 시스템 폴더에 속하며 관리자는 관리 양식 및 다른 시스템 폴더에 대한 공용 폴더 복제본 목록을 수동으로 업데이트해야 합니다.


공용 폴더 기반 타사 프로그램


사이트 간에 공용 폴더가 이동된 후 공용 폴더와 해당 공용 폴더의 LegacyExchangeDN 특성을 기반으로 하는 타사 프로그램이 제대로 작동하지 않을 수 있습니다.

프록시 주소


공용 폴더는 이전 사이트의 원래 프록시 주소를 유지합니다. 또한 공용 폴더는 받는 사람 정책이 관리 그룹 구성원을 기반으로 하더라도 관리 그룹 간에 이동될 때 새 프록시 주소를 얻지 않습니다.

받는 사람 업데이트 서비스는 이미 공용 폴더에 해당 유형의 프록시가 있는 경우 업데이트된 프록시를 지정하지 않습니다. 새 관리 그룹 구성원을 기반으로 사용자에게 적용되는 받는 사람 정책의 새 프록시 주소를 받으려면 받는 사람 정책에서 지금 적용을 누른 다음 받는 사람 업데이트 서비스를 다시 빌드합니다. 네트워크 성능에 영향을 미칠 수 있기 때문에 반드시 필요한 경우가 아니면 이렇게 하지 않는 것이 좋습니다.

프록시 주소가 업데이트되지 않더라도 전자 메일 메시지 전송은 영향을 받지 않습니다. 그러나 시스템에서 매우 특정한 제한 검사를 수행할 경우 주소가 업데이트되지 않으면 문제가 발생할 수 있습니다. 예를 들어 다음과 같은 시나리오를 생각해볼 수 있습니다.
  • AG1이 domain1.com에 대한 전자 메일 메시지를 받아들입니다.
  • AG2가 domain2.com에 대한 전자 메일 메시지를 받아들입니다.
  • 두 관리 그룹을 연결하는 커넥터는 조직 외부의 어느 누구도 해당 커넥터를 통해 전자 메일 메시지를 보낼 수 없도록 합니다.
  • 따라서 전자 메일 메시지가 NDR을 생성하고 커넥터를 통해 전송되지 않습니다.




DS/IS 일관성 조정자 실행


사이트 간 공용 폴더 이동 후 모든 디렉터리 복제가 완료될 때까지 Synchronized with the directory and reset the home server value 기능을 설정한 상태로 DS/IS(디렉터리 서비스/정보 저장소) 일관성 조정자를 실행하지 않는 것이 가장 좋습니다. 반드시 필요한 경우가 아니면 DS/IS 일관성 조정자를 실행하지 않는 것이 좋습니다. DS/IS 일관성 조정자를 실행하려면 먼저 사이트 간 공용 폴더 이동이 완료될 때까지 기다려야 합니다.
사이트 간 공용 폴더 이동 직후에 DS/IS 일관성 조정자를 실행하면 PFMigrate에 지정된 대상 사이트가 아닌 사이트로 공용 폴더가 이동될 수 있습니다. 이 문제는 다음과 같은 경우에 발생할 수 있습니다.
  • PFMigrate를 실행하여 사이트의 모든 공용 폴더에 대한 공용 폴더 복제본을 새 사이트의 대상 서버에 추가합니다.
  • PFMigrate를 실행하여 원본 사이트의 모든 서버에서 모든 공용 폴더 복제본을 삭제합니다.
  • 이동된 특성이 Active Directory에서 Exchange Server 5.5 디렉터리로 다시 복제되기 전에 관리자가 DS/IS 일관성 조정자를 실행합니다.
그러나 Exchange Server 5.5로 Active Directory가 복제된 후에는 DS/IS 일관성 조정자를 실행할 때 발생하는 위험이 없습니다.

관리 그룹 간 사서함 이동 후의 동작 문제 해결

Exchange Server 5.5 사용자와 Exchange Server 2003 사용자에게 미치는 영향

관리 그룹 간에 이동하거나 ADC가 Exchange Server 5.5 디렉터리 개체를 정리하는 동안 많은 메시지 배달 문제가 발생할 수 있습니다. 이 동작에 대비하려면 가능한 문제를 완전히 이해하는 것이 가장 좋습니다.

메일 전송 문제

사서함 이동 후 잠깐 동안 서버가 로컬 사이트에 있는 것처럼 다른 사이트에 있는 서버의 큐에 메시지가 대기할 수 있습니다. 이는 MTA(메시지 전송 에이전트)가 사이트 간에 사용자가 이동할 수 있는 방법을 이해하지 못하기 때문입니다. 따라서 MTA는 PR_IN_TRANSIT 블록이 해제된 후 몇 가지 사항을 부정확하게 가정합니다.

RPC(원격 저장 프로시저)를 통해 메시지 배달 시도가 이루어집니다. 이러한 시도는 다수의 사이트를 연결하는 커넥터가 X400 커넥터뿐이고 이들 사이트에서 같은 보안 컨텍스트(같은 서비스 계정)를 공유하지 않는 경우에 실패합니다. Exchange 5.5 서버에서 다음과 유사한 오류 메시지를 받을 수도 있습니다.



이벤트 종류: 경고
이벤트 원본: MSExchangeMTA
이벤트 범주: 인터페이스
이벤트 ID: 9318
사용자: N/A
컴퓨터: Exchange5.5ServerName
설명: An RPC communications error occurred. Unable to bind over RPC. Locality Table (LTAB) index: 6, NT/MTA error code: 1753. Comms error 1753, Bind error 0, Remote Server Name ExchangeServerName [MAIN BASE 1 500 %10] (14)



이 문제의 해결 방법은 사이트 간에 사이트 커넥터를 임시로 만드는 것입니다. 이렇게 하면 해당 서버 간에 직접 RPC 연결을 설정하고 이 연결을 통해 메일을 배달할 수 있습니다. 사이트 간 사서함 이동이 완료되고 MTA가 사용자의 정확한 경로를 올바르게 식별한 후에는 이 문제가 발생하지 않습니다.



받은 편지함 규칙


사용자와 해당 Exchange LegacyExchangeDN을 기반으로 하는 클라이언트쪽 받은 편지함 규칙이나 서버쪽 받은 편지함 규칙은 관리 그룹 간 사용자 이동 시 사용자의 LegacyExchangeDN이 변경되기 때문에 깨집니다. 그러나 사용자가 Exchange Server 2003 서비스 팩 1 이상을 기반으로 하는 서버로 이동하면 받은 편지함 규칙이 유지됩니다. 사용자의 LegacyExchangeDN이 변경되더라도 사서함 저장소의 변경을 통해 규칙이 제대로 작동할 수 있기 때문에 관리 그룹 간 이동 후 Exchange Server 2003 서비스 팩 1에서 받은 편지함 규칙이 그대로 유지되는 것입니다. Exchange 2003 서비스 팩 1 서버에서 규칙을 처리하는 동안 관리 그룹 간 이동 중에 추가된 X.500 프록시 주소를 LegacyExchangeDN 특성 대신 사용할 수 있습니다.

사용자가 Exchange Server 2003 서비스 팩 1 기반의 서버로 이동하지 않으면 관리 그룹 간에 이동된 사용자를 기반으로 하는 받은 편지함 규칙을 다시 만들어야 합니다.



전체 주소 목록의 이동된 사용자


이전 사이트의 원래 Exchange Server 5.5 개체가 숨겨진 동안이나 새 Exchange Server 5.5 개체가 Active Directory에서 새 사이트로 복제되기 전에 Exchange Server 5.5의 전체 주소 목록에서 관리 그룹 간에 이동된 사용자가 잠깐 사라질 수 있습니다. Active Directory, Exchange 2000 Server 및 Exchange Server 2003 전체 주소 목록에서는 관리 그룹 간에 이동된 사용자가 영향을 받지 않습니다.

프록시 주소


사용자는 이전 사이트의 원래 프록시 주소를 유지합니다. 그러나 사용자는 받는 사람 정책이 관리 그룹 구성원을 기반으로 하더라도 관리 그룹 간에 이동될 때 새 프록시 주소를 얻지 않습니다.

받는 사람 업데이트 서비스는 이미 사용자가 해당 유형의 프록시를 가지고 있는 경우 업데이트된 프록시를 지정하지 않습니다. 새 관리 그룹 구성원을 기반으로 사용자에게 적용되는 받는 사람 정책의 새 프록시 주소를 받으려면 받는 사람 정책에서 지금 적용을 누른 다음 받는 사람 업데이트 서비스를 다시 빌드합니다. 네트워크 성능에 영향을 미칠 수 있기 때문에 반드시 필요한 경우가 아니면 이렇게 하지 않는 것이 좋습니다.

프록시 주소가 업데이트되지 않더라도 전자 메일 메시지 전송은 영향을 받지 않습니다. 그러나 시스템에서 매우 특정한 제한 검사를 수행할 경우 주소가 업데이트되지 않으면 문제가 발생할 수 있습니다. 예를 들어 다음과 같은 시나리오를 생각해볼 수 있습니다.
  • AG1이 domain1.com에 대한 전자 메일 메시지를 받아들입니다.
  • AG2가 domain2.com에 대한 전자 메일 메시지를 받아들입니다.
  • 두 관리 그룹을 연결하는 커넥터는 조직 외부의 어느 누구도 해당 커넥터를 통해 전자 메일 메시지를 보낼 수 없도록 합니다.
  • 따라서 전자 메일 메시지가 NDR을 생성하고 커넥터를 통해 전송되지 않습니다.

Outlook Web Access 로그온 프로세스


프런트 엔드/백 엔드 구현에서 사용자는 명시적 로그온이나 암시적 로그온을 입력하여 Outlook Web Access(OWA)를 통해 자신의 사서함에 액세스할 수 있습니다. 명시적 로그온의 URL은 사용자가 액세스하려는 서버와 사서함을 지정하며 http://servername/exchange/username/ 형식을 사용합니다. 여기서 servername은 OWA 프런트 엔드 또는 백 엔드 서버의 이름이고 username은 사용자의 Microsoft Windows 계정 이름입니다. 사용자가 명시적 로그온을 사용하여 OWA에 액세스할 때 로그온이 제대로 작동하지 않을 수 있습니다. 이 문제는 사용자가 관리 그룹 간에 이동될 때 해당 사용자가 OWA에 사용하는 HTTP 가상 디렉터리가 변경되기 때문에 발생합니다. 사용자가 OWA에 사용하는 HTTP 가상 디렉터리는 해당 사용자의 Exchange 사서함 백 엔드 서버가 변경되기 때문에 변경됩니다. 로그온 오류는 새 HTTP 가상 디렉터리의 SMTP 주소가 사용자의 SMTP 주소와 다를 경우에 발생합니다.

참고 기본 Exchange Outlook Web Access 가상 디렉터리는 기본 받는 사람 정책과 해당 정책의 SMTP 주소를 사용하도록 모두 하드 코딩되어 있습니다. 새 가상 디렉터리를 만드는 경우에만 다른 SMTP 주소가 있는 다른 받는 사람 정책을 사용할 수 있습니다.

이 문제는 다음 두 시나리오 중 하나에서 발생할 수 있습니다.
  • 시나리오 1: 원본 사이트가 사이트마다 SMTP 주소가 다른 순수 Exchange Server 5.5 사이트이고 현재 사서함에 Exchange Server 2003 서비스 팩 1 서버의 기본 Exchange 가상 디렉터리 SMTP 주소와 일치하지 않는 Exchange Server 5.5의 SMTP 주소가 있는 경우. 사용자가 Exchange Server 5.5에서 Exchange Server 2003으로 이동된 경우 해당 사용자는 Outlook Web Access에서 명시적 로그온을 사용하여 Exchange Server 2003 서비스 팩 1 서버에 로그온하려고 해도 로그온할 수 없습니다.
  • 시나리오 2: 혼합 또는 순수 Exchange 2000 Server/Exchange Server 2003 환경에서 사용자가 현재 관리자가 만들었지만 기본 가상 디렉터리가 아닌 전용 가상 디렉터리를 Outlook Web Access에 사용하고 있는 경우. 전용 가상 디렉터리는 Exchange 조직의 사서함에 사용되는 SMTP 주소도 제공하는 받는 사람 정책의 SMTP 주소를 사용합니다. 즉, SMTP 주소가 일치합니다. 새 사이트로 이동할 때 사용자는 기본 Exchange Outlook Web Access 가상 디렉터리를 사용하도록 설정된 새 Exchange 사서함 서버로 이동됩니다. 이 기본 Exchange 가상 디렉터리는 기본 받는 사람 정책을 사용하며 사용자에게 없는 다른 SMTP 주소를 가지고 있습니다. 따라서 사용자가 Exchange Server 5.5에서 Exchange Server 2003으로 이동된 경우 해당 사용자는 Outlook Web Access에서 명시적 로그온을 사용하여 Exchange Server 2003 서비스 팩 1 서버에 로그온하려고 해도 로그온할 수 없습니다.
시나리오 1과 2의 문제를 해결하려면 다음 해결 방법 중 하나를 사용합니다.
  • 사용자가 이동된 새 사이트에 새 사서함 서버에 대한 전용 가상 디렉터리를 만듭니다. 새 전용 가상 디렉터리가 사용자의 SMTP 주소가 있는 받는 사람 정책을 가리키도록 합니다.
  • 혼합 사이트나 순수 Exchange Server 2000 시나리오에서 이동된 사용자에게 적용되는 받는 사람 정책에 기본 받는 사람 정책의 SMTP 주소를 추가합니다. 받는 사람 업데이트 서비스가 업데이트된 후 사용자는 기본 가상 디렉터리와 일치하는 추가 SMTP 프록시를 가지게 됩니다.
  • 이동된 사용자에게 올바른 SMTP 주소를 수동으로 추가합니다.
Exchange Server 2003 서비스 팩 1에는 암시적 로그온이나 명시적 로그온에서 SMTP 주소를 사용하여 이 문제를 해결할 수 있도록 하는 수정 프로그램이 있습니다. Outlook Web Access는 Exchange Server 2003 서비스 팩 1 기반 서버에 연결할 때 다음 시나리오에서 항상 제대로 작동합니다.
  • 암시적 로그온
    예를 들어 OWA 액세스 URL을 다음과 같은 형식으로 입력합니다.
    http://Server/exchange
  • UPN(사용자 이름) 또는 SMTP 주소를 사용하는 명시적 로그온
    예를 들어 OWA 액세스 URL을 다음과 같은 형식으로 입력합니다.
    http://server/exchange/user@Domain_Name.com

사용자의 별칭을 사용하는 명시적 로그온을 사용하려고 할 때 사용자에게 HTTP 가상 디렉터리의 SMTP 주소가 없으면 로그온이 완료되지 않습니다. 예를 들어 OWA 액세스 URL을 http://Server/exchange/User 형식으로 입력하면 Exchange 서버 사서함이 액세스되지 않습니다. 이 문제는 사용자의 별칭을 사용하는 명시적 로그온이 OWA에 사용될 때마다 발생하며 관리 그룹 간 이동 시나리오에만 해당되는 문제가 아닙니다.



약속 있음/약속 없음 정보 및 리소스 사서함


약속 있음/약속 없음 정보는 사이트 간 사서함 이동 후 다시 게시해야 합니다. 사용자 사서함의 경우 이 동작은 사용자가 Outlook을 사용하여 Exchange 서버에 로그온하고 일정 작업을 수행한 지 15분 후에 이루어집니다. 예를 들어 사용자가 회의 요청을 승인, 제거 또는 생성하면 일정의 약속 있음/약속 없음 정보가 15분 후에 다시 게시됩니다.

회의실 같은 리소스 사서함의 소유자는 사서함을 열고 일정 작업을 수행하여 약속 있음/약속 없음 정보를 다시 게시해야 합니다.

이 동작은 대상 사이트에 사용자의 새 LegacyExchangeDN 특성에 대한 약속 있음/약속 없음 메시지가 없지만 일정이 변경될 때까지 Outlook이 업데이트를 게시하지 않고 Outlook의 "로컬" 약속 있음/약속 없음 캐시가 정리되지 않기 때문에 발생합니다. 이 동작은 GUIDGen 프로세스를 실행하여 사이트 시스템 폴더를 다시 설정하는 경우에도 발생합니다.

또는 UpdateFB 도구를 사용하여 이 약속 있음/약속 없음 다시 게시 프로세스를 자동화할 수 있습니다.

UpdateFB 도구에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
294282 Updatefb.exe를 사용하여 없는 약속 있음/약속 없음 데이터를 다시 게시하는 방법


오프라인 주소록

오프라인 주소록 다운로드 및 원격 사이트


사용자가 Exchange Server 2003 이하 버전이 설치된 원격 사이트에서 캐시된 모드로 Outlook 2003을 실행할 때는 원격 사이트에 있는 모든 클라이언트의 전체 오프라인 주소록 다운로드를 지원하기에 충분한 대역폭이 있는지 확인해야 합니다.



저속 연결을 통한 원격 사이트


캐시된 모드로 Outlook 2003을 사용하는 사서함이 사이트를 통해 또는 그 밖의 방법으로 원격 Exchange Server 5.5 서버에서 중앙 Exchange 2003 SP1 서버로 이동되는 경우에는 전체 오프라인 주소록을 다운로드해야 합니다. 또한 디렉터리가 상당히 변경되거나 새 관리 그룹이 추가 또는 제거되는 경우에도 캐시된 모드 사용자에 대해 전체 오프라인 주소록 다운로드가 생성됩니다. 따라서 원격 사이트는 원격 사이트에 있는 모든 클라이언트의 전체 오프라인 주소록을 지원하기에 충분한 대역폭이 있는지 확인해야 합니다.



전체 오프라인 주소록 다운로드에 대한 자세한 내용


대개 Outlook 클라이언트는 오프라인 주소록의 변경 내용만 반영된 다운로드를 보게 됩니다. 이 다운로드는 전체 오프라인 주소록 다운로드의 작은 하위 집합으로서, 전체 주소 목록 대신 변경 사항만 포함합니다. 그러나 Outlook 클라이언트가 전체 오프라인 주소록을 다운로드해야 할 경우가 있습니다. 새 계정이 많이 추가되거나 이름이 많이 변경되는 등 디렉터리가 크게 변경되거나 새 Exchange 관리 그룹이 추가 또는 제거될 경우 캐시된 모드의 모든 클라이언트가 전체 오프라인 주소록으로 업데이트됩니다. 또한 Exchange Server 5.5에서 새 Exchange Server 2003 서버로 이동되는 클라이언트도 새 전체 오프라인 주소록을 받게 됩니다.

Exchange Server 2003에서 전체 OAB 다운로드가 미치는 영향을 제한하는 방법은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
867623 전체 오프라인 주소록 다운로드를 조절하여 Exchange Server 2003에서 LAN에 미치는 영향 제한


디렉터리 업데이트 대기

관리자는 NDR을 생성하지 않고 전자 메일 메시지가 전송되도록 디렉터리 업데이트가 이루어질 때까지 기다려야 합니다.

알려진 문제: 개체 이동 후의 동작

연락처와 메일 그룹에 메일을 보내는 사용자의 경우 Exchange Server 5.5와 Exchange Server 2003에서 메시지 배달이 영향을 받는다

관리 그룹 간에 이동하거나 ADC가 Exchange Server 5.5 디렉터리 개체를 정리하는 동안 사용자가 연락처와 메일 그룹에 전자 메일 메시지를 보내면 많은 메시지 배달 문제가 발생할 수 있습니다.

받은 편지함 규칙


관리 그룹 간 이동 동안 메일 그룹이 이동되면 보낸 사람이나 받는 사람으로 DL에 기반하여 메시지를 처리하는 받은 편지함 규칙이 Exchange Server 2003 서비스 팩 1 이전의 Exchange 서버에서 호스팅되는 사서함에 대해 제대로 작동하지 않습니다. 이러한 규칙을 다시 만들거나 해당 규칙이 있는 사서함을 Exchange 2003 SP1을 실행하고 있는 서버로 이동해야 합니다.



전체 주소 목록의 이동된 공용 폴더


연락처/메일 그룹이 이동되면 이전 사이트의 원래 Exchange Server 5.5 개체가 숨겨진 동안이나 새 Exchange Server 5.5 개체가 Active Directory에서 새 사이트로 복제되기 전에 Exchange Server 5.5의 전체 주소 목록에서 사라질 수 있습니다. Active Directory, Exchange 2000 Server 전체 주소 목록 또는 Exchange Server 2003 전체 주소 목록의 이동된 개체는 영향을 받지 않습니다.



프록시 주소


이동된 개체는 이전 사이트의 원래 프록시 주소를 유지합니다. 그러나 이동된 개체는 받는 사람 정책이 관리 그룹 구성원을 기반으로 하더라도 관리 그룹 간에 이동될 때 새 프록시 주소를 얻지 않습니다.

받는 사람 업데이트 서비스는 이미 이동된 개체에 같은 유형의 프록시가 있는 경우 업데이트된 프록시를 지정하지 않습니다. 새 관리 그룹 구성원을 기반으로 개체에 적용되는 받는 사람 정책의 새 프록시 주소를 받으려면 받는 사람 정책에서 지금 적용을 누른 다음 받는 사람 업데이트 서비스를 다시 빌드합니다. 네트워크 성능에 영향을 미칠 수 있기 때문에 반드시 필요한 경우가 아니면 이렇게 하지 않는 것이 좋습니다.
프록시 주소가 업데이트되지 않더라도 전자 메일 메시지 전송은 영향을 받지 않습니다. 그러나 시스템에서 매우 특정한 제한 검사를 수행할 경우 주소가 업데이트되지 않으면 문제가 발생할 수 있습니다. 예를 들어 다음과 같은 시나리오를 생각해볼 수 있습니다.
  • AG1이 domain1.com에 대한 전자 메일 메시지를 받아들입니다.
  • AG2가 domain2.com에 대한 전자 메일 메시지를 받아들입니다.
  • 두 관리 그룹을 연결하는 커넥터는 조직 외부의 어느 누구도 해당 커넥터를 통해 전자 메일 메시지를 보낼 수 없도록 합니다.
  • 따라서 전자 메일 메시지가 NDR을 생성하고 커넥터를 통해 전송되지 않습니다.


사이트 간 이동된 연락처에서 조직 간 ADC가 X.500 주소를 덮어쓴다


다음과 같은 시나리오를 생각해볼 수 있습니다. 조직 간 CA(연결 동의)가 조직에 연락처를 만듭니다. 이 연락처는 다른 조직의 사서함을 나타냅니다. 연락처가 사이트 간에 이동되면 원본 사이트에 있는 연락처의 원래 디렉터리 이름이 이동된 연락처에 X.500 주소 형식으로 지정됩니다. 그러나 연락처가 나타내는 사서함이 변경되면 해당 변경 사항이 이동된 연락처 개체에 다시 복제되고 ADC가 X.500 주소를 덮어씁니다.

이 문제를 해결하려면 다음 절차를 하나 이상 사용하십시오.
  • 새 사이트에 맞게 ADC를 다시 구성한 다음 모든 X.500 주소를 손실하는 도구를 실행합니다.
  • 사이트 간 이동 전에 Exchange Server 5.5에서 LegacyExchangeDN을 내보낸 다음 Exchange Server 5.5 사서함에서 X.500 주소로 LegacyExchangeDN을 가져옵니다.
  • Exchange 전용 모드로 전환하고 연락처를 이동하지 않습니다.


ADC가 완료될 때까지 기다린다


Active Directory와 Exchange Server 5.5 간 복제, 사이트 내 복제 및 사이트 간 복제가 완료될 때까지 기다려야 합니다. Exchange Server 5.5 디렉터리가 동기화되고 ADC가 실행되어 변경 사항을 수정할 때까지 전자 메일 메시지 전송과 다른 작업이 영향을 받습니다.

DS/IS 일관성 조정자를 실행한다


공용 폴더에 대한 액세스 권한이 부여된 메일 그룹이 사이트 간에 이동되면 메일 그룹이 계속 공용 폴더에 액세스할 수 있도록 패치가 적용된 DS/IS 일관성 조정자 도구를 실행해야 합니다.

참조

자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
836489 Exchange Server 5.5와의 혼합 모드 사이트 통합에 업데이트가 필요하다
843107 pfMigrate 도구를 사용하여 Exchange Server 2003 서비스 팩 1에서 사이트 간 공용 폴더 이동 작업을 수행하는 방법





Microsoft 제품 관련 기술 전문가들과 온라인으로 정보를 교환하시려면 Microsoft 뉴스 그룹에 참여하시기 바랍니다.

속성

기술 자료: 841659 - 마지막 검토: 2014년 1월 23일 목요일 - 수정: 3.2
본 문서의 정보는 다음의 제품에 적용됩니다.
  • Microsoft Exchange Server 2003 Service Pack 1
키워드:?
kbnosurvey kbarchive kbinfo kbexchange2003sp1fix KB841659

피드백 보내기

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com