다음을 통해 공유

프록시 및 리디렉션 이해

  • 아티클

 

적용 대상: Exchange Server 2010 SP2, Exchange Server 2010 SP3

마지막으로 수정된 항목: 2016-11-28

Microsoft Exchange Server 2010 조직에서 한 클라이언트 액세스 서버는 조직 내 다른 클라이언트 액세스 서버의 프록시 서버 역할을 할 수 있습니다. 이는 조직의 다양한 Active Directory 사이트에 여러 클라이언트 액세스 서버가 있으며 그 중 적어도 하나의 사이트가 인터넷에 노출되지 않는 경우에 유용합니다.

또한 클라이언트 액세스 서버는 Microsoft Office Outlook Web App URL 및 Exchange ActiveSync 장치에 대한 리디렉션을 수행할 수 있습니다. 리디렉션은 사용자가 자신의 로컬 Active Directory 사이트가 아닌 다른 곳의 클라이언트 액세스 서버에 연결하거나, Active Directory 사이트 간에 사서함이 이동한 경우에 유용합니다. 또한 사용자가 실제로 보다 효과적인 URL을 사용해야 하는 경우에도 유용합니다. 예를 들어 사용자는 자신의 사서함이 있는 Active Directory 사이트에 더 가까운 URL을 사용해야 합니다.

클라이언트 액세스 서버의 응답은 프로토콜에 따라 다를 수 있습니다. 그러나 일반적으로 클라이언트 액세스 서버는 클라이언트 액세스 서버가 속한 사이트와 다른 Active Directory 사이트에 사서함이 있는 사용자에 대한 요청을 받은 경우 다음 작업을 수행합니다. 이 경우 서버는 클라이언트 액세스 서버의 관련 가상 디렉터리에서 사용자의 사서함과 같은 Active Directory 사이트에 있지 않은 ExternalURL 속성의 존재 여부를 확인합니다. ExternalURL 속성이 있고 클라이언트 유형이 Outlook Web App 또는 Exchange ActiveSync와 같이 리디렉션을 지원하는 경우 클라이언트 액세스 서버는 해당 클라이언트에 대한 리디렉션을 실행합니다. ExternalURL 속성이 없거나 클라이언트 유형이 POP3 또는 IMAP4와 같이 리디렉션을 지원하지 않는 경우 클라이언트 액세스 서버는 대상 Active Directory 사이트에 프록시 연결을 시도합니다.

이 항목에서는 프록싱 및 리디렉션에 대해 알아보고 각각을 사용하는 경우 및 각 시나리오에 대해 클라이언트 액세스 서버를 구성하는 방법을 설명합니다.

참고

조직에 여러 Active Directory 사이트가 있는 경우가 아니라면 프록시 또는 리디렉션을 위해 Exchange 2010을 구성할 필요가 없습니다. 그러나 이 항목 후반에서 설명하는 바와 같이 URL의 부하 분산을 구성해야 할 수 있습니다.

참고

인터넷에 노출되지 않는 클라이언트 액세스 서버에는 다른 클라이언트 액세스 서버에서 들어오는 프록시 처리된 트래픽을 허용하기 위한 별도의 SSL(Secure Sockets Layer) 인증서가 필요 없습니다. 기본적으로 Exchange 2010으로 설치된 자체 서명된 인증서를 사용할 수 있습니다. 그러나 일반적으로 Outlook Web App 또는 Outlook과 같은 내부 클라이언트는 이러한 인증서를 신뢰하지 않기 때문에 해당 인증서를 사용하면 인증서 경고가 발생하는 것이 일반적입니다. 클라이언트 액세스 서버와 동일한 Active Directory 사이트에 자체 서명된 인증서를 가진 내부 클라이언트가 있는 경우에는 자체 서명된 인증서를 클라이언트가 신뢰하는 인증 기관에서 발행한 인증서로 바꿔야 합니다.

목차

프록싱 개요

리디렉션 개요

네트워크 부하 분산을 사용하는 프록싱

클라이언트 액세스 방법 요약

프록싱 성능 및 확장성

프록싱 개요

Microsoft Exchange Server 2003에서 프런트 엔드 서버는 HTTP를 통해 백 엔드 서버와 통신합니다. Exchange Server 2007 및 Exchange 2010에서 클라이언트 액세스 서버는 RPC를 통해 Exchange 사서함 서버와 통신합니다. Exchange 2010 사서함 서버가 포함된 모든 Active Directory 사이트에 Exchange 2010 클라이언트 액세스 서버가 있어야 합니다. 한 클라이언트 액세스 서버에서 다른 클라이언트 액세스 서버로 트래픽을 보낼 때 프록싱이 발생합니다. Exchange 2010 클라이언트 액세스 서버는 다음 상황에서 요청을 프록시 처리할 수 있습니다.

  • Exchange 2010 클라이언트 액세스 서버 간   두 Exchange 2010 클라이언트 액세스 서버 간에 요청을 프록시 처리하면 여러 Active Directory 사이트가 있는 조직에서 한 클라이언트 액세스 서버를 인터넷 연결 서버로 지정하고 이 서버에서 인터넷이 없는 사이트의 클라이언트 액세스 서버로 요청을 프록시 처리하도록 할 수 있습니다. 그러면 인터넷에 연결된 클라이언트 액세스 서버에서 사용자의 사서함에 가장 가까운 클라이언트 액세스 서버로 요청을 프록시 처리합니다.

  • Exchange 2010 클라이언트 액세스 서버와 Exchange 2007 클라이언트 액세스 서버 간   하나의 Exchange 2010 사이트 내에서 또는 Exchange 2007 사이트 간에 Active Directory 클라이언트 액세스 서버와 Active Directory 클라이언트 액세스 서버 간에 요청을 프록시 처리하면 동일 조직에서 Exchange 2010 및 Exchange 2007을 동시에 사용할 수 있습니다. 업그레이드 및 동시 사용 방법에 대한 자세한 내용은Exchange 2003 클라이언트 액세스에서 업그레이드 및 Exchange 2007 클라이언트 액세스에서 업그레이드를 참조하십시오.

프록시는 Outlook Web App, Exchange ActiveSync, ECP(Exchange 제어판), POP3, IMAP4 및 Exchange 웹 서비스를 사용하는 클라이언트에 지원됩니다. 대상 클라이언트 액세스 서버가 원본 클라이언트 액세스 서버와 같은 Microsoft Exchange 버전 또는 그 이전의 Microsoft Exchange 버전을 실행하는 경우 한 클라이언트 액세스 서버에서 다른 클라이언트 액세스 서버로 프록시 처리할 수 있습니다. Exchange 2007 및 Exchange 2010이 혼합된 환경에서의 레거시 호스트 이름 및 버전별 URL에 대한 자세한 내용은 Exchange 2007 클라이언트 액세스에서 업그레이드를 참조하세요. Exchange 2010 및 Exchange 2013이 혼합된 환경에서의 레거시 호스트 이름 및 버전별 URL에 대한 자세한 내용은 레거시 Exchange 호스트 이름 만들기를 참조하세요.

경고경고:
NTLM 인증을 사용하는 IMAP4 클라이언트가 대상 사서함이 없는 Active Directory 사이트의 클라이언트 액세스 서버에 연결을 시도하면 연결이 실패합니다. IMAP4 클라이언트가 Active Directory 사이트 간에 프록시되도록 하려면 대체 인증 방법을 선택해야 합니다.

참고

인터넷 기반 클라이언트의 액세스를 허용하려는 각 Exchange 조직에서는 적어도 하나의 Active Directory 사이트가 인터넷에 연결되어야 합니다. 인터넷에 연결되지 않은 모든 Active Directory 사이트는 인터넷에 연결된 클라이언트 액세스 서버를 통해 외부 클라이언트의 모든 관련 요청을 프록시 처리합니다.

클라이언트 액세스 프록싱

앞의 그림에서 사용자 1의 사서함은 사서함 서버 1에 있고, 사용자 2의 사서함은 사서함 서버 2에 있으며, 사용자 3의 사서함은 사서함 서버 3에 있습니다. 각 사서함 서버는 다른 Active Directory 사이트에 있습니다. 사용자 1은 프록시를 사용하지 않고 클라이언트 액세스 서버 1을 통해 사서함에 액세스할 수 있고, 사용자 2는 클라이언트 액세스 서버 2를 통해 사서함에 액세스할 수 있습니다. 사용자 3이 클라이언트 액세스 서버 1 또는 2를 통해 사서함에 액세스하려고 하면 서버는 클라이언트 서버 3에 액세스 요청을 프록시 처리합니다. 클라이언트 액세스 서버 3은 인터넷에 연결하지 않고도 방화벽 안의 다른 서버로부터 요청을 수신할 수 있습니다. 사용자에게는 프록시 과정이 표시되지 않습니다.

참고

서로 다른 사이트에 있는 클라이언트 액세스 서버 간의 통신은 HTTPS(보안 HTTP)를 통해 이루어지지만, 클라이언트 액세스 서버는 기본적으로 사용되는 인증서의 상태를 검사하지 않습니다. 인증서는 인증이 아니라 암호화를 위해서만 사용되므로 이름 불일치, 만료 날짜, 트러스트 상태 등은 무시됩니다.

프록싱 개요

리디렉션 개요

사서함이 포함된 사이트가 아닌 다른 Active Directory 사이트에 있는 인터넷 연결 클라이언트 액세스 서버에 액세스하는 Outlook Web App 사용자를 사서함 서버와 같은 사이트에 있는 클라이언트 액세스 서버(인터넷에 연결된 경우)로 리디렉션할 수 있습니다. Outlook Web App 사용자가 사서함 서버가 포함된 Active Directory 사이트의 외부에 있는 클라이언트 액세스 서버에 연결하려고 시도하면 사서함에 대한 올바른 클라이언트 액세스 서버의 링크가 있는 웹 페이지가 표시됩니다. 이를 수동 리디렉션이라고 합니다. Exchange 2010 SP2에서 관리자는 사용자가 인식하지 못하는 사이에 사이트 간 자동 리디렉션 프로세스가 발생하도록 이 리디렉션을 구성할 수 있습니다. 자세한 내용은 이 항목 뒤에 나오는 사이트 간 자동 리디렉션을 참조하십시오.

참고

Office 365와 함께 온-프레미스 Exchange Server를 사용하는 하이브리드 환경에서는 사이트 간 자동 리디렉션을 사용할 수 없습니다.

사서함이 포함된 사이트가 아닌 다른 Exchange ActiveSync 사이트에 있는 인터넷 연결 클라이언트 액세스 서버에 액세스하는 Active Directory 사용자를 사서함 서버와 같은 사이트에 있는 클라이언트 액세스 서버로 리디렉션할 수 있습니다. 다만, 클라이언트 액세스 서버가 인터넷에 연결되어 있고 클라이언트의 휴대폰이나 장치가 Exchange 2007 및 Exchange 2010과 통신할 때 사용되는 프로토콜의 기본 리디렉션 로직을 정확히 구현한 경우에 한합니다. Exchange ActiveSync 사용자의 리디렉션은 장치가 사용하는 URL을 포함한 HTTP 451 오류 코드를 장치에 전송하는 방법으로 이루어집니다. 그러면 장치는 새 URL을 사용하도록 자체 재구성됩니다.

다음 그림에서는 여러 Active Directory 사이트에 여러 클라이언트 액세스 서버가 있는 조직에서 리디렉션의 작동 방법을 보여줍니다.

Exchange 2010의 Exchange ActiveSync 및 Outlook Web App 리디렉션

앞의 그림에서 사용자 1은 일반적으로 휴대폰을 사용하여 Active Directory 사이트 1의 사서함에 액세스합니다. 그러면 관리자는 Active Directory 사이트 2의 사서함 서버 2로 사서함을 이동합니다. 다음 번에 장치가 동기화를 시도하면 서버는 HTTP 451 상태 오류로 응답합니다. 여기에는 해당 사용자의 장치에서 사용해야 할 URL이 포함됩니다. 3단계에서는 장치가 자체 재구성된 후 지정된 URL에 연결됩니다. 사서함이 Active Directory 사이트 2에 있는 사용자 2는 인터넷으로 클라이언트 액세스 서버 1에 연결하여 Outlook Web App로 사서함을 엽니다. 수동 리디렉션을 사용할 경우 사용자가 인증하면 바로 클라이언트 액세스 서버 1은 사용자에게 Active Directory 사이트 2에 있는 클라이언트 액세스 서버의 Outlook Web App URL에 대한 링크와 함께 페이지를 제공합니다. 사용자가 이 링크를 클릭하면 Active Directory 사이트 2로 이동되며 다시 로그인하여 자신의 사서함에 액세스합니다. 자동 리디렉션을 사용할 경우 사용자가 인증하면 Active Directory 사이트 2에 있는 클라이언트 액세스 서버의 Outlook Web App URL로 자동으로 리디렉션됩니다.

사이트 간 자동 리디렉션

참고

Office 365와 함께 온-프레미스 Exchange Server를 사용하는 하이브리드 환경에서는 사이트 간 자동 리디렉션을 사용할 수 없습니다.

Exchange 2010 SP2를 사용하여 관리자가 사이트 간 자동 리디렉션을 구성할 수 있습니다. 사이트 간 리디렉션은 같은 Exchange 조직의 다른 Active Directory 사이트에 있는 CAS에 보낸 클라이언트 요청에 대해 자동 리디렉션을 수행합니다. 예를 들면 Active Directory 사이트 A에 사서함이 있고 Active Directory 사이트 B의 Outlook Web App URL에 액세스하는 사용자는 사이트 A의 Active Directory에 대한 Outlook Web App URL로 자동으로 리디렉션됩니다.

사이트 간 자동 리디렉션을 구성하려면 관리자가 Set-OWAVirtualDirectory cmdlet에 추가된 새 CrossSiteRedirectType 매개 변수를 사용해야 합니다. 이 매개 변수는 두 가지 설정이 가능합니다. 기본 설정은 Manual입니다.

  • 자동 이 설정을 구성하면 클라이언트 액세스 서버가 다른 Active Directory 사이트에 있는 클라이언트 액세스 서버나 서버 배열로 Outlook Web App 요청을 리디렉션해야 할 때마다 사용자의 웹 브라우저가 자동으로 리디렉션됩니다. 폼 기반 인증을 원본 및 대상 CAS OWA 가상 디렉터리에서 구성한 경우(SSL 필요) 자동 리디렉션이 또한 single sign-on 이벤트입니다. 리디렉션이 발생하려면 대상 클라이언트 액세스 서버 Outlook Web App 가상 디렉터리에 ExternalURL 값을 구성해야 합니다.

  • 수동 이 설정을 구성하면 사용자가 잘못된 URL에 액세스하고 있으며 사서함에 대한 올바른 Outlook Web App URL에 액세스하는 링크를 클릭해야 한다는 알림이 표시됩니다. 이 알림은 클라이언트 액세스 서버가 Outlook Web App 요청을 다른 Active Directory 사이트에 있는 클라이언트 액세스 서버 또는 서버 배열로 리디렉션해야 한다고 판단하는 경우에만 발생합니다. 리디렉션이 발생하려면 대상 클라이언트 액세스 서버 Outlook Web App 가상 디렉터리에 ExternalURL 값을 구성해야 합니다.

예를 들면 다음과 같습니다.

Set-OWAVirtualDirectory -Identity "Contoso\owa (Default Web site)" -CrossSiteRedirectType Silent

Set-OwaVirtualDirectory cmdlet에 대한 자세한 내용은 다음을 참조하십시오. Set-OwaVirtualDirectory

Exchange ActiveSync 프록시 및 리디렉션

다음 일련의 단계에서는 휴대폰을 사용하여 CAS-01이라는 Exchange 2010 클라이언트 액세스 서버에 연결하는 사용자에 대해 들어오는 요청을 처리하는 방법을 설명합니다.

  1. 클라이언트 액세스 서버는 Active Directory를 쿼리하여 사용자의 사서함 위치 및 사서함 서버에 설치된 Microsoft Exchange 버전을 확인합니다.

  2. 사용자의 사서함이 Exchange 2003 서버에 있을 경우 들어오는 요청은 사용자 사서함과 Exchange ActiveSync 가상 디렉터리를 호스팅하는 Exchange 2003 서버로 직접 프록시 처리됩니다. 기본적으로 Exchange 2003에서는 Exchange ActiveSync 가상 디렉터리가 모든 사서함 서버에 설치되었습니다. Active Directory은 위치 확인에 Exchange 2003 사이트를 사용하지 않기 때문에 사용자 사서함의 Active Directory 사이트가 이 경우에는 해당되지 않습니다. 연결은 항상 Exchange 2010 클라이언트 액세스 서버에서 Exchange 2003 사서함 서버로 직접 이루어집니다. 

    참고

    Exchange 2003 서버에 사서함이 있는 사용자가 Exchange 2010 클라이언트 액세스 서버를 통해 Exchange ActiveSync를 사용하려고 하면 오류가 발생하고, Exchange 2003 서버의 Microsoft-Server-ActiveSync 가상 디렉터리에 대해 Windows 통합 인증을 사용하도록 설정한 경우가 아니면 동기화를 수행할 수 없습니다. Windows 통합 인증을 사용하면 Exchange 2010 클라이언트 액세스 서버와 Exchange 2003 백 엔드 서버가 통신할 수 있습니다.

  3. 사용자의 사서함이 Exchange 2007 사서함 서버에 있을 경우 CAS-01은 사용자의 사서함 서버와 같은 Exchange 2007 사이트에서 Active Directory 클라이언트 액세스 서버를 찾습니다. 이것은 CAS-01와 같은 Active Directory 사이트일 수 있습니다. CAS-01은 ExternalURL 설정에 관계없이 Exchange 2007 클라이언트 액세스 서버의 InternalURL에 Exchange ActiveSync 요청을 프록시 처리합니다. 이 요청은 IIS의 Microsoft Server Exchange ActiveSync 가상 디렉터리에 있는 /Proxy 가상 디렉터리로 이동하며, 기본적으로 Windows 통합 인증이 활성화되어 있습니다.

  4. 사용자 사서함이 CAS-01과 동일한 Active Directory 사이트의 Exchange 2010 사서함 서버에 있는 경우 CAS-01은 사서함에 대한 액세스를 제공합니다. 사용자 사서함이 다른 Active Directory 사이트의 Exchange 2010 사서함 서버에 있을 경우 CAS-01은 사용자의 사서함 서버와 같은 Active Directory 사이트에서 클라이언트 액세스 서버를 찾습니다. CAS-01은 해당 Exchange 2010 사이트에서 Active Directory 가상 디렉터리에 ExternalURL 속성이 구성된 Exchange ActiveSync 클라이언트 액세스 서버가 있는지 확인합니다. 이 속성이 있는 경우, CAS-01은 해당 ExternalURL 값을 포함한 HTTP 오류 코드 451을 발행하고 클라이언트가 해당 위치로 리디렉션되도록 지시합니다. 설정된 ExternalURL 값이 없다면 InternalURL 속성에 따라 지정된 FQDN을 사용하는 클라이언트 액세스 서버, 특히 /Proxy 가상 디렉터리에 프록시 연결됩니다. 이러한 가상 디렉터리는 IIS에서 Exchange ActiveSync 가상 디렉터리 아래에 위치하며 기본적으로 Windows 통합 인증을 사용하도록 설정되어 있습니다.

    중요

    기본 인증을 사용하는 가상 디렉터리 간에는 프록시가 지원되지 않습니다. 서로 다른 서버에 있는 Exchange ActiveSync 가상 디렉터리 간에 클라이언트 통신을 프록시 처리하려면 /Proxy 가상 디렉터리에서 Windows 통합 인증을 사용해야 합니다.

프록싱 개요

Outlook Web App의 프록시 및 리디렉션

다음 일련의 단계에서는 Outlook Web App을 사용하여 CAS-01이라는 Exchange 2010 클라이언트 액세스 서버에 연결하는 사용자에 대해 들어오는 요청을 처리하는 방법을 설명합니다.

  1. 클라이언트 액세스 서버는 Active Directory를 쿼리하여 사용자의 사서함 위치 및 사서함 서버에 설치된 Microsoft Exchange 버전을 확인합니다.

  2. 사용자의 사서함이 Exchange 2003 서버에 있고 사용자가 https://domain name/owa를 사용하여 Outlook Web App에 액세스하려고 하면 오류가 수신됩니다. 이는 Exchange 2010 클라이언트 서버가 Outlook Web App 사서함에 대한 Exchange 2003 액세스를 직접 제공할 수 없기 때문입니다. 그러나 Exchange 2003에서 Exchange 2010으로 마이그레이션할 때와 같이 관리자가 Exchange 2010에서 Exchange 2003으로의 리디렉션을 구성한 경우에는 Outlook Web App 가상 디렉터리의 Exchange2003URL 속성이 인터넷에 연결된 Exchange 2003 서버의 값으로 설정됩니다.

  3. 사용자의 사서함이 Exchange 2007 사서함 서버에 있을 경우 CAS-01은 사용자의 사서함 서버와 같은 Active Directory 사이트에서 클라이언트 액세스 서버를 찾습니다. Exchange 2007 사서함 서버가 CAS-01과 같은 Active Directory 사이트에 있는 경우에는 다음 네 가지 작업 중 하나가 발생합니다.

    • CAS-01이 Exchange 2010 클라이언트 액세스 서버의 InternalAuthenticationMethods 설정과 동일한 ExternalAuthenticationMethods 설정을 가진 Exchange 2007 ExternalURL 속성을 찾습니다. 이러한 설정이 발견되면 CAS-01은 이 외부 URL로 리디렉션됩니다. 원본 및 대상 CAS에서 FBA(양식 기반 인증)을 사용한 경우 원본 CAS는 숨겨진 양식이 사용자의 자격 증명 및 FBA 설정과 함께 리디렉션 URL이 포함된 브라우저로 다시 돌아가는 문제가 있습니다. 이 문제는 사용자가 인식하지 못합니다.

    • 일치하는 ExternalURL 설정이 없는 경우, CAS-01은 일치 여부와 관계없이 ExternalURL 속성이 구성된 Exchange 2007 클라이언트 액세스 서버를 찾습니다. 이러한 서버가 발견되면 CAS-01은 이 외부 URL로 리디렉션됩니다. 그러면 사용자 인증을 요구하는 메시지가 나타납니다.

    • 일치하는 ExternalURL 설정이 없으면 CAS-01은 Exchange 2010 클라이언트 액세스 서버의 InternalAuthenticationMethods 설정과 일치하는 InternalAuthenticationMethods 설정을 가진 InternalURL 속성이 있는 Exchange 2007 클라이언트 액세스 서버를 찾습니다. 이러한 서버가 발견되면 CAS-01은 이 내부 URL로 리디렉션됩니다. 폼 기반 인증을 사용하는 경우에는 Single Sign-On 리디렉션이 됩니다.

    • 일치하는 InternalURL이 없으면 CAS-01은 일치 여부와 관계없이 InternalURL이 구성된 Exchange 2007 클라이언트 액세스 서버를 찾습니다. 이러한 서버가 발견되면 CAS-01은 이 내부 URL로 리디렉션됩니다. 그러면 사용자 인증을 요구하는 메시지가 나타납니다.

    Exchange 2007 사서함 서버가 다른 Active Directory 사이트에 있는 경우 CAS-01은 해당 Active Directory 사이트에 ExternalURL 속성이 설정되어 있는지 확인합니다. 설정되어 있고 사이트 간 자동 리디렉션을 사용하지 않는 경우 CrossSiteRedirectType 값이 Manual로 설정되고 수동 리디렉션이 실행됩니다. 이 시나리오에서는 클릭하여 지정 URL로 리디렉션할 수 있는 링크가 제공됩니다.

    사이트 간 자동 리디렉션을 사용하는 경우 CrossSiteRedirectType 값이 Silent로 설정되고 지정된 URL로 자동으로 리디렉션됩니다. ExternalURL 속성이 없고 /OWA 가상 디렉터리에 대한 인증 방법이 Windows 통합 인증으로 설정된 경우 CAS-01은 InternalURL 속성에 의해 지정된 클라이언트 액세스 서버로 사용자 요청을 프록시 처리합니다.

    중요

    Exchange 2010 클라이언트 서버가 다른 Outlook Web App 사이트의 Exchange 2007 클라이언트 액세스 서버로 Active Directory 요청을 프록시 처리할 수 있도록 하려면 대상 Exchange 2007 사이트에 있는 Active Directory 클라이언트 액세스 서버의 최상위 버전 폴더를 %installpath%\ClientAccess\OWA\ 폴더에서 프록시 요청을 하는 Exchange 2010 클라이언트 액세스 서버 상의 동일한 경로로 복사해야 합니다.

    중요

    Exchange 2010 클라이언트 액세스 서버는 동일한 Active Directory 사이트의 Exchange 2007 클라이언트 액세스 서버로 Outlook Web App 요청을 프록시 처리하지 않습니다. 동일한 Active Directory 사이트 내의 모든 요청은 구성된 속성에 따라 클라이언트 액세스 서버의 InternalURL 또는 ExternalURL 속성을 사용하여 Exchange 2007 클라이언트 액세스 서버로 리디렉션됩니다.

  4. 사용자 사서함이 CAS-01과 동일한 Active Directory 사이트의 Exchange 2010 사서함 서버에 있는 경우 CAS-01은 사서함에 대한 액세스를 제공합니다. 사용자 사서함이 다른 Active Directory 사이트의 Exchange 2010 사서함 서버에 있을 경우 CAS-01은 사용자의 사서함 서버와 같은 Active Directory 사이트에서 클라이언트 액세스 서버를 찾습니다. 서버가 있는 경우 Exchange 2010은 해당 Active Directory 사이트에 ExternalURL 속성이 설정되어 있는지 여부를 확인합니다. 속성이 설정되어 있고 사이트 간 자동 리디렉션을 사용한 경우 클릭하여 지정 URL로 리디렉션할 수 있는 링크가 제공됩니다. 사이트 간 자동 리디렉션을 사용하면 지정된 URL로 자동으로 리디렉션됩니다. 설정된 ExternalURL이 없고 가상 디렉터리에 대한 인증 방법이 Windows 통합 인증으로 설정된 경우 CAS-01은 InternalURL 속성에 의해 지정된 클라이언트 액세스 서버로 사용자 요청을 프록시 처리합니다.

Exchange 제어판에 대한 프록시

Exchange 2010은 사용자 및 조직 관리자에게 사서함 또는 조직의 설정을 구성할 수 있는 웹 기반 인터페이스를 제공합니다. ECP(Exchange 제어판)는 Outlook Web App 또는 Outlook 2010의 옵션 메뉴에서 음성 메일 옵션을 선택하거나 메시지 추적 정보를 요청하거나 모바일 알림을 구성하는 방법으로 액세스합니다. Outlook에서 이 옵션을 선택하면 웹 브라우저 세션이 시작됩니다.

세션의 대상은 Outlook 클라이언트의 현재 연결 상태에 따라 다릅니다. Outlook 클라이언트가 RPC over TCP를 사용하여 연결된 경우에는 ECP 가상 디렉터리의 InternalURL 값에 연결됩니다. 클라이언트가 외부에서 Outlook 사용 기능을 통해 연결된 경우 Outlook 클라이언트는 브라우저 세션을 시작합니다. 브라우저 세션은 ECP 가상 디렉터리의 ExternalURL 값에 연결하도록 시도합니다. 자동 검색 서비스를 통해 Outlook 클라이언트에 URL이 제공됩니다.

내부 클라이언트가 TCP를 통해 연결된 경우 ECP 세션은 항상 사용자 사서함과 동일한 Active Directory 사이트에 있는 클라이언트 액세스 서버에 연결됩니다. 이 시나리오에서 프록시는 사용되지 않습니다. 기업 네트워크 외부의 클라이언트가 외부에서 Outlook 사용 기능을 통해 연결될 때 사용자 사서함이 인터넷에 연결되지 않은 사이트에 있는 경우, 클라이언트는 ECP 가상 디렉터리의 외부 URL 또는 인터넷에 연결된 Active Directory 사이트의 외부 URL에 대한 브라우저 세션을 엽니다.

ECP의 프록시 로직은 Outlook Web App의 경우와 같습니다. 사용자 사서함이 요청을 수신하는 클라이언트 액세스 서버와 동일한 Active Directory 사이트의 Exchange 2010 사서함 서버에 있는 경우 이 클라이언트 액세스 서버는 사서함에 대한 액세스를 제공합니다. 사용자 사서함이 다른 Active Directory 사이트의 Exchange 2010 사서함 서버에 있을 경우 클라이언트 액세스 서버는 사용자의 사서함 서버와 같은 Active Directory 사이트에서 클라이언트 액세스 서버를 찾습니다. 원래 클라이언트 액세스 서버는 사용자의 요청을 클라이언트 액세스 서버로 프록시 처리합니다.

ECP는 리디렉션을 수행하지만, 사용자가 ECP에 액세스하기 위해 명시적으로 URL을 입력하지 않는 한 리디렉션은 거의 이루어지지 않습니다. 사용자가 Outlook Web App에서 ECP에 액세스하는 경우 Outlook Web App은 사용자가 정확한 URL을 사용하는지 확인합니다. 사용자가 Outlook 2010을 사용하는 경우에는 사용자가 ECP의 정확한 URL을 사용하는지 확인하는 기능을 Outlook 및 자동 검색 서비스가 담당합니다.

프록싱 개요

Exchange 웹 서비스에 대한 프록시

Exchange 웹 서비스는 클라이언트 응용 프로그램에서 Exchange 저장소 항목을 관리하고 Exchange 서버 기능에 액세스할 수 있는 XML 메시징 인터페이스를 제공합니다. 이 기능은 프록시, 리디렉션 및 클라이언트의 관점에서 볼 때 일반적으로 다음 중 한 가지 상황에 주로 사용됩니다.

  • 가용성 서비스 요청

  • 자동 검색 요청

  • 자동 회신(부재 중) 상태 설정 및 확인

Exchange 웹 서비스를 사용하여 작성된 응용 프로그램은 필요한 경우 Active Directory 사이트 간에 프록시 처리되는 자동 회신(부재 중) 메시지 설정과 같은 작업에 대한 프록시 동작을 사용할 수 있습니다.

다음 단계는 CAS-01이라는 Exchange 2010 클라이언트 액세스 서버에 가용성 서비스 요청을 하는 사용자에 대해 들어오는 요청을 처리하는 방법입니다. 사용자는 Outlook Web App을 사용하여 동일한 Exchange 조직에 있는 다른 사용자의 가용성을 확인합니다.

  1. CAS-01은 Active Directory를 쿼리하여 사용자 사서함의 위치 및 사서함 서버에 설치된 Microsoft Exchange 버전을 확인합니다.

  2. 사용자의 사서함이 Exchange 2003 서버에 있는 경우 Outlook Web App은 Exchange 2003 서버의 /Public 가상 디렉터리에 HTTP로 연결하여 약속 있음/없음 시스템 폴더에서 요청된 정보를 검색합니다.

  3. 사용자 사서함이 Exchange 2007 사서함 서버에 있을 경우 사용자에게 오류가 반환됩니다. Exchange 2007 사서함 서버에 사서함이 포함된 Exchange 조직에는 외부에서 액세스할 수 있는 Exchange 2007 클라이언트 액세스 서버가 있어야 합니다. 자동 검색 서비스는 올바른 Exchange 웹 서비스 URL을 클라이언트에 반환해야 합니다. 이 URL은 사용자 사서함이 있는 사서함 서버의 버전과 일치해야 합니다.

  4. 사용자의 사서함이 CAS-01과 동일한 Active Directory 사이트의 Exchange 2010 사서함 서버에 있는 경우 CAS-01은 요청된 정보를 검색하기 위해 사서함 자체에 액세스합니다. 사용자의 사서함이 다른 Active Directory 사이트의 Exchange 2010 사서함 서버에 있는 경우 CAS-01은 /EWS 가상 디렉터리의 InternalURL 속성에 따라 지정된 FQDN을 사용하여 해당 Active Directory 사이트의 클라이언트 액세스 서버로 프록시 처리합니다.

    중요

    Exchange 클라이언트 액세스 서버는 ExternalURL 속성의 설정 여부와 관계없이 가용성 서비스 요청을 한 서버에서 다른 서버로 프록시 처리합니다.

    중요

    일부 Exchange 웹 서비스 응용 프로그램은 매우 강력한 클라이언트 액세스 서버 선호도를 가진 GetEvents 및 Unsubscribe와 같은 웹 메서드를 사용합니다. 한 클라이언트 액세스 서버가 이러한 요청 중 하나를 다른 Active Directory 사이트로 프록시 처리해야 하는 경우에는 항상 호스트 서버 자체의 FQDN에 설정되어야 하는 클라이언트 액세스 서버의 InternalNLBBypassURL 속성을 사용할 수 있습니다. 그러면 요청을 하는 클라이언트 액세스 서버는 대상 Active Directory 사이트의 특정 클라이언트 액세스 서버에 대한 선호도를 유지할 수 있습니다.

Exchange 웹 서비스 자체는 리디렉션 기능을 제공하지 않습니다. 이는 응용 프로그램에 URL을 제공하는 데 사용되는 자동 검색 서비스가 특정 사서함에 액세스하는 데 필요한 URL을 제공하기 때문입니다. 예를 들어, 사서함이 Active Directory 사이트 간에 이동하는 경우 Outlook은 다음에 쿼리를 발행할 때 업데이트된 Active Directory 사이트 고유의 URL을 자동 검색 서비스로부터 수신합니다. 그러면 클라이언트가 사서함이 있는 사이트가 아닌 Active Directory 사이트의 클라이언트 액세스 서버로 가용성 서비스 요청을 하게 되는 경우도 있습니다. 하지만 이런 경우에도 가용성 서비스는 요청을 처리하고 필요에 따라 프록시 처리하므로 사용자에게는 아무런 영향이 없습니다.

중요

Exchange 2007 사서함 서버에 사서함이 포함된 Exchange 조직에는 외부에서 액세스할 수 있는 Exchange 2007 클라이언트 액세스 서버가 있어야 합니다. 자동 검색 서비스가 올바른 Exchange 웹 서비스 URL을 요청 클라이언트에 반환하는 경우 이 URL은 사용자 사서함이 있는 서버의 버전과 일치합니다. Exchange 2007 사서함 서버 및 Exchange 2010 사서함 서버 모두에 사서함이 포함된 Exchange 조직의 경우 Exchange 웹 서비스에 대해 두 개의 외부 URL을 구성해야 합니다. 설치된 각 버전의 Exchange에 하나씩 구성해야 합니다.

POP3 및 IMAP4에 대한 프록시

Exchange 2010은 클라이언트 액세스 서버와 Active Directory 사이트 간에 POP3 및 IMAP4 세션을 프록시 처리할 수 있습니다.

다음 단계는 POP3 클라이언트를 사용하여 CAS-01이라는 Exchange 2010 클라이언트 액세스 서버에 요청하는 사용자에 대해 들어오는 요청을 처리하는 방법을 보여줍니다.

  1. CAS-01은 Active Directory를 쿼리하여 사용자 사서함의 위치 및 사서함 서버에 설치된 Microsoft Exchange 버전을 확인합니다.

  2. 사용자의 사서함이 Exchange 2003 서버에 있는 경우 CAS-01은 사용자 사서함을 호스팅하는 Exchange 2003 서버에서 실행되는 POP3 서비스에 프록시 연결합니다.

  3. 사용자의 사서함이 Exchange 2007 사서함 서버에 있는 경우 CAS-01은 사용자의 사서함 서버와 동일한 Exchange 2007 사이트(CAS-01과 동일한 Active Directory 사이트에 있을 수도 있음)에서 Active Directory 클라이언트 액세스 서버를 찾습니다. CAS-01은 클라이언트 액세스 서버로 요청을 프록시 처리합니다.

  4. 사용자 사서함이 CAS-01과 동일한 Active Directory 사이트의 Exchange 2010 사서함 서버에 있는 경우 CAS-01은 사서함 자체에 액세스합니다. 사용자의 사서함이 다른 Active Directory 사이트의 Exchange 2010 사서함 서버에 있는 경우 CAS-01은 해당 서버에 대한 POP 구성의 InternalConnectionSettings 속성에 따라 지정된 FQDN을 사용하여 클라이언트 액세스 서버로 프록시 처리합니다.

    중요

    POP3 또는 IMAP4 서비스에 대한 InternalURL 또는 ExternalURL 설정은 없으며, Exchange 2010 클라이언트 액세스 서버는 필요할 때 POP3 및 IMAP4 서비스 요청을 한 서버에서 다른 서버로 프록시 처리합니다.

    중요

    다른 Active Directory 사이트로 프록시 처리하려는 클라이언트 액세스 서버는 POP3 또는 IMAP4 서비스가 실제로 원격 클라이언트 액세스 서버에서 실행되는지 여부를 확인하지 않습니다. 따라서 서비스가 원격 Active Directory 사이트의 모든 클라이언트 액세스 서버에서 실행되는지 확인할 뿐만 아니라 서비스용 부하 분산 장치 사용도 고려해야 합니다. 부하 분산에 대해서는 이 항목의 뒷부분에서 설명합니다.

프록싱 개요

프록싱 구성

클라이언트 액세스 서버가 인터넷에 연결된 경우 EMC(Exchange 관리 콘솔) 또는 Exchange 관리 셸을 사용하여 /Microsoft-Server-ActiveSync, /OWA, /ECP 및 /EWS 가상 디렉터리의 ExternalURL 속성을 설정합니다. EWS 가상 디렉터리는 셸을 사용해서만 구성할 수 있습니다. InternalURL 속성은 Exchange 2010 초기 설정 과정에서 자동으로 구성되며 부하 분산 솔루션을 사용하려는 경우에만 변경해야 합니다. ExternalURL 속성에는 Exchange 조직에 대해 DNS에 등록된 FQDN이 포함되어야 합니다.

다음 표에는 URL https://mail.contoso.com을 사용하여 Outlook Web App에 액세스하는 Exchange 조직에 대해 인터넷에 연결된 클라이언트 액세스 서버의 ExternalURL 및 InternalURL 속성에 적합한 값이 제공됩니다. 두 번째 표에는 동일한 조직을 위한 두 번째 Active Directory 사이트에서 인터넷 연결이 되지 않은 클라이언트 액세스 서버에 적합한 ExternalURL 및 InternalURL 속성 값이 제공됩니다. 모든 가상 디렉터리에 대한 인증 방법이 Windows 통합 인증으로 설정되었는지 확인해야 합니다. SSL/TLS를 사용하여 사용자의 기본 인증 자격 증명을 프록시 처리하는 POP3 및 IMAP4를 제외한 다른 인증 방법을 사용하는 가상 디렉터리에는 프록시가 지원되지 않습니다.

참고

셸을 사용하여 새 Outlook Web App 가상 디렉터리를 만드는 경우 이 가상 디렉터리에서 InternalURL 속성을 수동으로 구성해야 합니다.

인터넷에 연결된 클라이언트 액세스 서버에 대한 InternalURL 및 ExternalURL 설정

Exchange 2010 서비스 InternalURL 설정 ExternalURL 설정

Outlook Web App

https://정규화된 컴퓨터 이름/OWA

https://mail.contoso.com/OWA

Exchange ActiveSync

https://정규화된 컴퓨터 이름/Microsoft-Server-ActiveSync

https://mail.contoso.com/Microsoft-Server-ActiveSync

Exchange 웹 서비스

https://정규화된 컴퓨터 이름/EWS/Exchange.asmx

https://mail.contoso.com/EWS/Exchange.asmx

Exchange 제어판

https://정규화된 컴퓨터 이름/ECP

https://mail.contoso.com/ECP

인터넷에 연결되지 않은 클라이언트 액세스 서버에 대한 InternalURL 및 ExternalURL 설정

Exchange 2010 서비스 InternalURL 설정 ExternalURL 설정

Outlook Web App

https://정규화된 컴퓨터 이름/OWA

$Null

Exchange ActiveSync

https://정규화된 컴퓨터 이름/Microsoft-Server-ActiveSync

$Null

Exchange 웹 서비스

https://정규화된 컴퓨터 이름/EWS/Exchange.asmx

$Null

Exchange 제어판

https://정규화된 컴퓨터 이름/ECP

$Null

리디렉션 구성

둘 이상의 Active Directory 사이트가 인터넷에 연결된 경우 사이트 간 리디렉션이 가능하게 하려면 EMC 또는 셸을 사용하여 /OWA 및 /Microsoft-Server-ActiveSync 가상 디렉터리의 ExternalURL 속성을 설정합니다. InternalURL 속성은 Exchange 2010 초기 설정 과정에서 자동으로 구성되며 부하 분산 솔루션을 사용하려는 경우에만 변경해야 합니다. 다음 두 표에서는 Contoso라는 회사의 두 Active Directory 사이트에 있는 클라이언트 액세스 서버의 ExternalURL 설정과 InternalURL 설정을 보여줍니다. 두 사이트는 usa.contoso.com과 europe.contoso.com입니다.

참고

셸을 사용하여 새 Outlook Web App 가상 디렉터리를 만드는 경우 이 가상 디렉터리에서 InternalURL 속성을 수동으로 구성해야 합니다.

usa.contoso.com 사이트에 있는 인터넷 연결된 클라이언트 액세스 서버에 대한 InternalURL 및 ExternalURL 설정

Exchange 2010 서비스 InternalURL 설정 ExternalURL 설정

Outlook Web App

https://정규화된 컴퓨터 이름/OWA

https://usa.contoso.com/OWA

Exchange 제어판

https://정규화된 컴퓨터 이름/ECP

https://usa.contoso.com/ECP

Exchange ActiveSync

https://정규화된 컴퓨터 이름/Microsoft-Server-ActiveSync

https://usa.contoso.com/ Microsoft-Server-ActiveSync

Exchange 웹 서비스

https://정규화된 컴퓨터 이름/EWS/Exchange.asmx

https://usa.contoso.com/EWS/Exchange.asmx

europe.contoso.com 사이트에 있는 인터넷 연결된 클라이언트 액세스 서버에 대한 InternalURL 및 ExternalURL 설정

Exchange 2010 서비스 InternalURL 설정 ExternalURL 설정

Outlook Web App

https://정규화된 컴퓨터 이름/OWA

https://europe.contoso.com/OWA

Exchange 제어판

https://정규화된 컴퓨터 이름/ECP

https://europe.contoso.com/ECP

Exchange ActiveSync

https://정규화된 컴퓨터 이름/Microsoft-Server-ActiveSync

https://europe.contoso.com/ Microsoft-Server-ActiveSync

Exchange 웹 서비스

https://정규화된 컴퓨터 이름/EWS/Exchange.asmx

https://europe.contoso.com/EWS/Exchange.asmx

참고

ExternalURL 속성이 Active Directory 사이트 한 개 이상에서 Exchange ActiveSync 가상 디렉터리에 설정되지 않은 경우에는 해당 휴대폰을 구성할 때 자동 검색 서비스가 실패합니다. 이는 ExternalURL 속성에 설정된 값이 자동 검색 프로세스 과정에서 휴대폰에 전달되기 때문입니다.

프록싱 개요

네트워크 부하 분산을 사용하는 프록싱

조직에 여러 Active Directory 사이트가 있고 각 사이트에 여러 클라이언트 액세스 서버가 있을 경우 그러한 서버에 직접 액세스하려는 사용자를 위해 NLB(네트워크 부하 분산)을 사용하여 각 사이트의 클라이언트 액세스 서버 간에 프록시 처리된 트래픽 부하를 분산시킬 수 있습니다. 부하 분산 장치 배포만으로 트래픽을 효율적으로 분산시킬 수 없습니다. 또한 InternalURL 및 ExternalURL 속성을 추가로 구성해야 합니다. 부하 분산 배열에서 같은 Active Directory 사이트 내에 클라이언트 액세스 서버만 포함하는 것이 좋습니다. 인터넷에 연결된 Active Directory 사이트와 인터넷에 연결되지 않은 Active Directory 사이트에 NLB를 배포할 수 있습니다.

다음 표는 인터넷에 연결된 사이트와 인터넷에 연결되지 않은 사이트 모두에서 클라이언트 액세스 서버의 가상 디렉터리에 대해 구성해야 할 설정을 보여줍니다. 부하 분산 장치 또는 서비스를 확인하려면 DNS에서 NLB의 FQDN을 구성해야 합니다. 그러면 부하 분산 솔루션이 적절한 클라이언트 액세스 서버로 트래픽을 전달합니다.

NLB를 사용하는 조직에서 클라이언트 액세스 서버의 가상 디렉터리 설정

가상 디렉터리 /service InternalURL ExternalURL (인터넷에 연결된 Active Directory 사이트) ExternalURL (인터넷에 연결되지 않은 Active Directory 사이트)

/OWA

NLB FQDN(다음 지침 참조)

NLB FQDN

$null

/ECP

NLB FQDN(다음 지침 참조)

NLB FQDN

$null

/Microsoft-Server-ActiveSync

NLB FQDN

NLB FQDN

$null

/OAB

NLB FQDN

NLB FQDN

$null

/EWS

NLB FQDN

NLB FQDN

$null

POP/IMAP

(InternalConnectionsSettings)

NLB FQDN

해당 없음

해당 없음

다음 지침에 따라 InternalURL 속성을 설정하십시오.

  • 내부 Outlook 2010 사용자가 있을 경우 Active Directory 사이트의 모든 클라이언트 액세스 서버에서 /OWA 및 /ECP 가상 디렉터리에 대한 InternalURL 속성은 해당 사이트에 있는 서버의 NLB FQDN으로 설정할 수 있습니다.

  • Active Directory 사이트에 있는 클라이언트 액세스 서버가 다른 Active Directory 사이트에 있는 클라이언트 액세스 서버의 Outlook Web App 또는 ECP 프록시 요청 대상인 경우 선호도를 유지할 수 있도록 부하 분산 장치를 구성해야 합니다. 이는 인터넷에 연결된 사이트의 클라이언트 액세스 서버에서 각 개별 요청에 대한 서버를 선택하고 고유한 선호도를 유지 관리 수 없기 때문입니다.

다음 표는 NLB(네트워크 부하 분산)를 이용하는 조직에서 가상 디렉터리에 필요한 다양한 인증 설정을 보여줍니다. NLB를 사용하는 조직에서는 클라이언트 연결을 위해 특정 클라이언트 액세스 서버 URL 대신 NLB URL이 사용됩니다.

내결함성 및 부하 분산을 위해 NLB URL을 사용하는 조직에서 클라이언트 액세스 서버의 가상 디렉터리 인증 설정

가상 디렉터리 /service 인터넷에 연결된 Active Directory 사이트 인터넷에 연결되지 않은 Active Directory 사이트

/OWA

Microsoft Forefront TMG(Threat Management Gateway) 2010 또는 Microsoft Forefront UAG(Unified Access Gateway) 2010을 사용하며 폼 기반 인증을 사용하는 경우에는 방화벽 규칙 위임 설정에 따라 Windows 기본 인증 또는 통합 인증을 사용합니다.

사전 인증 없이 인터넷 트래픽이 클라이언트 액세스 서버로 전달되는 경우에는 폼 기반 인증을 사용합니다.

/OWA 및 /ECP 가상 디렉터리에서는 동일한 인증 방법을 사용해야 합니다.

Windows 통합 인증

/ECP

Forefront TMG 또는 Forefront UAFG를 사용하며 폼 기반 인증을 사용하는 경우에는 방화벽 규칙 위임 설정에 따라 Windows 기본 인증 또는 통합 인증을 사용합니다.

사전 인증 없이 인터넷 트래픽이 클라이언트 액세스 서버로 전달되는 경우에는 폼 기반 인증을 사용합니다.

/OWA 및 /ECP 가상 디렉터리에서는 동일한 인증 방법을 사용해야 합니다.

Windows 통합 인증

/Microsoft-Server-ActiveSync

기본 인증.

기본 인증(프록시는 /Proxy 하위 가상 디렉터리를 사용하여 수행됩니다.)

/OAB

방화벽 규칙 위임 설정에 따른 Windows 기본 인증 또는 통합 인증.

방화벽 규칙 위임 설정에 따른 Windows 기본 인증 또는 통합 인증(OAB 요청이 Active Directory 사이트 간에 프록시 처리되지 않습니다. 이 가상 디렉터리는 Outlook 클라이언트에서만 사용됩니다.)

/EWS

기본(옵션 - 방화벽 규칙 위임 설정에 따라).

Windows 통합 인증이 필요합니다.

Windows 통합 인증

POP/IMAP

클라이언트 연결 방법에 필요한 경우

클라이언트 연결 방법에 필요한 경우

프록싱 개요

Active Directory 사이트 간의 프록시 처리에서 클라이언트 액세스 서버가 사용하는 부하 분산 로직

프록시 시도의 대상이 될 사이트에 여러 클라이언트 액세스 서버가 존재하며 사용자의 사서함이 위치한 서버가 클라이언트 액세스 서버와 사서함 서버가 결합된 서버인 경우 소스 Active Directory 사이트의 클라이언트 액세스 서버는 결합된 해당 클라이언트 액세스 서버와 사서함 서버를 항상 프록시 시도의 대상으로 선택합니다.

Outlook Web App, ECP 및 Exchange 웹 서비스는 가용성 서비스 및 Exchange ActiveSync와 다른 방법으로 부하 분산을 처리합니다. Outlook Web App, ECP 및 Exchange 웹 서비스는 동일한 Active Directory 사이트 내의 여러 클라이언트 액세스 서버에서 배포될 때 자체적으로 부하 분산을 구현합니다. https://mail.contoso.com/owa를 통해 Outlook Web App에 액세스하려고 시도했는데 CAS-01로 프록시 처리되었으면 다음 번에 Outlook Web App에 액세스하려고 시도할 때 CAS-02의 동시 연결 수가 더 적더라도 다시 CAS-01로 프록시 처리됩니다. 이는 재인증 또는 데이터 재요청 없이 장기 실행 트랜잭션을 완료하기 위한 것이며, 이를 선호도라고 합니다. CAS-01을 사용할 수 없는 경우 사용자는 CAS-02로 프록시 처리되며 재인증이 필요할 수도 있습니다.

Exchange 웹 서비스는 대상 서버의 InternalURL 속성이 NLB URL로 구성됨에도 불구하고 Active Directory 사이트 간에 프록시 처리할 때 선호도를 유지할 수 있습니다. 이는 선호도를 필요로 하는 응용 프로그램에 대해 프록시 요청을 하는 클라이언트 액세스 서버가 대상 서버에서 InternalNLBBypassURL 속성을 사용하기 때문입니다. InternalNLBBypassURL 속성은 대상 서버의 FQDN으로 구성되며 기본적으로 Windows 인증을 사용합니다.

참고

Outlook Web App, ECP 및 Exchange 웹 서비스의 경우 쿠키 기반 또는 IP 기반 선호도에 대해 방화벽을 구성해야 합니다. 그러면 특정 클라이언트 응용 프로그램이 매번 동일한 서버로 연결되도록 할 수 있습니다. 이 프로세스는 각 요청에 대해 SSL 협상이 반복적으로 수행되지 않도록 하는 데 필요합니다. 클라이언트 응용 프로그램부터 트랜잭션에 연관된 최종 클라이언트 액세스 서버에 이르기까지 선호도를 유지하는 것이 중요합니다.

참고

클라이언트 액세스 서버에서는 InternalNLBBypassURL 속성의 값을 변경하지 마십시오. 변경할 경우 프록시 처리된 Exchange 웹 서비스 요청이 중단됩니다.

Exchange ActiveSync의 경우에는 이 프로세스가 다릅니다. 인터넷에 연결된 클라이언트 액세스 서버가 인터넷에 연결되지 않은 클라이언트 액세스 서버로 요청을 프록시 처리할 때 요청하는 클라이언트 액세스 서버는 대상 사이트에서 클라이언트 액세스 서버를 찾은 후 InternalURL 속성에서 구성된 값을 사용하여 연결을 시도합니다. 서버가 응답하지 않으면 요청이 실패하고 클라이언트에 오류가 반환됩니다. NLB 배열에서 라운드 로빈 부하 분산을 구현하고 InternalURL 속성을 부하 분산 값으로 설정하는 것이 좋습니다.

또한 가용성 서비스에 대한 부하 분산을 수행하는 것도 좋습니다. 가용성 서비스 요청에서는 연결 상태를 유지 관리할 필요가 없습니다. 다시 말해서, 동일한 클라이언트로부터 가용성 서비스 요청 두 개가 연속적으로 들어오더라도 성능에 영향을 미치지 않고 요청을 대상 Active Directory 사이트의 다른 클라이언트 액세스 서버로 프록시 처리할 수 있으며 InternalURL 속성이 부하 분산 값으로 설정된 경우에는 인증 문제가 발생하지 않습니다. 뿐만 아니라 InternalURL 속성을 부하 분산 값으로 설정하면 Outlook 2007 및 Outlook 2010 클라이언트에 내부적으로 도움이 됩니다. 이는 자동 검색 서비스가 가용성 서비스 요청을 완료할 수 있도록 InternalURL 속성에 설정된 부하 분산 값을 이러한 클라이언트에 제공하기 때문입니다.

네트워크 부하 분산에 대한 자세한 내용은 Exchange 2010의 부하 분산 이해를 참조하십시오.

참고

많은 배포에서 클라이언트 액세스 서버 역할과 허브 전송 서버 역할은 같은 컴퓨터에 설치됩니다. 이 토폴로지에서 허브 전송 서버 역할과는 별도로 클라이언트 액세스 서버 역할에 대한 NLB를 구성할 수 있습니다. 현재 NLB는 허브 전송 서버 역할에 지원되지 않습니다. 클라이언트 액세스 서버 역할에 대해서는 지원됩니다. 허브 전송 서버 역할이 아니라 클라이언트 액세스 서버 역할에 대해 NLB를 구성하려면 클라이언트 액세스에 대해 포트 80 및 443을 구성합니다. 허브 전송 서버 역할은 소프트웨어 내에서 고유의 고가용성을 구현합니다.

프록싱 개요

클라이언트 액세스 방법 요약

다음 표에서는 Exchange 2010에 액세스하는 데 사용되는 프로토콜 및 이 프로토콜이 프록시와 리디렉션에 사용되는 방법을 요약하여 보여줍니다.

리디렉션 및 프록싱을 위한 클라이언트 액세스 프로토콜

프로토콜/응용 프로그램 클라이언트 액세스 서버 간에 지원되는 리디렉션 클라이언트 액세스 서버 간에 지원되는 프록싱 Comments

Outlook Web App

예

예

Outlook Web App을 사용하려면 각 Active Directory 사이트에 클라이언트 액세스 서버가 있어야 합니다.

Exchange 제어판

예

예

ECP를 사용하려면 각 Active Directory 사이트에 클라이언트 액세스 서버가 있어야 합니다.

Exchange ActiveSync

예

예

Exchange ActiveSync를 사용하려면 각 Active Directory 사이트에 클라이언트 액세스 서버가 있어야 합니다.

Exchange 웹 서비스

아니요(자동 검색 서비스가 응용 프로그램에 올바른 ExternalURL 값 제공)

예

Exchange 웹 서비스를 사용하려면 각 Active Directory 사이트에 클라이언트 액세스 서버가 있어야 합니다.

가용성 서비스

아니요(자동 검색 서비스가 응용 프로그램에 올바른 ExternalURL 값 제공)

예

가용성 서비스를 사용하려면 각 Active Directory 사이트에 클라이언트 액세스 서버가 있어야 합니다.

POP3 및 IMAP4

아니요

예

POP3 및 IMAP4를 사용하려면 각 Active Directory 사이트에 클라이언트 액세스 서버가 있어야 합니다.

프록싱 성능 및 확장성

Exchange 2010 프록시 환경에서는 클라이언트 액세스 서버가 동시에 많은 요청을 받으면 성능이 자주 저하될 수 있습니다. 이 문제는 ASP.NET에서 보낸 웹 서비스 요청으로 인해 스레드 및 사용 가능한 연결이 모두 사용되어 자주 발생합니다. 이로 인해 클라이언트 액세스 서버에서 요청을 거부하거나 요청이 처리되는 동안 대기 시간이 길어질 수 있습니다.

이 문제를 해결하려면 클라이언트 액세스 서버에서 Machine.config 파일을 편집하여 여러 ASP.NET 매개 변수를 구성합니다. 이 매개 변수를 구성하는 방법은 Microsoft 기술 자료 문서 821268, ASP.NET 응용 프로그램에서 웹 서비스를 요청하면 경합, 성능 저하 및 교착 상태가 발생한다를 참조하십시오.

Exchange 2010 프록시 환경에서는 기술 자료 문서 821268에서 설명한 두 매개 변수를 서로 다르게 설정해야 합니다. 프로세서당 스레드를 36개 허용하고 maxconnections 값을 2,000으로 설정하는 것이 좋습니다.

서버 성능에 대한 자세한 내용은 Windows Server 2003에서 .NET Framework 관리를 참조하십시오.

 © 2010 Microsoft Corporation. 모든 권리 보유.