RPC 클라이언트 액세스 이해

  • 아티클

 

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

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

MicrosoftExchange Server 2007에서는 클라이언트 액세스 서버 역할이 Exchange 사서함에 대한 들어오는 클라이언트 연결을 처리하기 위해 도입되었습니다. 대부분의 유형의 클라이언트 연결은 클라이언트 액세스 서버에 대해 설정되었지만, Microsoft Office Outlook은 MAPI 프로토콜로 내부에서 실행되는 동안 계속 사서함 서버에 직접 연결되어 있었습니다.

이러한 MAPI 연결을 클라이언트 액세스 서버에서 처리할 수 있도록 새 서비스가 Exchange Server 2010에서 도입되었습니다. RPC 클라이언트 액세스 서비스는 클라이언트 액세스 서버의 공통된 단일 경로를 통해 데이터 액세스를 제공합니다. 계속 사서함 서버에 대해 직접 만들어지는 공용 폴더 요청은 예외입니다. 이 변경 사항을 통해 더 일관성 있게 클라이언트에 비즈니스 논리를 적용하고 장애 조치(failover)가 발생할 경우 클라이언트 환경을 개선할 수 있게 되었습니다.

목차

RPC 클라이언트 액세스 서비스 및 주소록 서비스

RPC 클라이언트 액세스 서비스의 장점

클라이언트 액세스 서버 배열

RPC 클라이언트 액세스 서비스 및 주소록 서비스 구성

RPC 클라이언트 액세스 서비스 및 주소록 서비스

들어오는 Outlook 사서함 연결을 클라이언트 액세스 서버로 이동한 것 외에, Exchange 2010에서는 디렉터리 액세스도 클라이언트 액세스 서버에서 처리됩니다. 디렉터리에 대한 자세한 내용은 주소록 서비스 이해를 참조하십시오.

Microsoft Outlook은 계속 사서함 서버에 직접 연결하여 공용 폴더 데이터베이스에 액세스합니다. 클라이언트가 공용 폴더 액세스를 위해 사서함 서버에 연결하려고 시도하는 경우 RPC 클라이언트 액세스 서비스(MsExchangeRpc)가 RPC 끝점에 응답합니다. 끝점이 사서함 서버 역할이 설치된 서버에 있는 경우 RPC 클라이언트 액세스 서비스는 공용 폴더 로그온만 허용하며 클라이언트 액세스 서버 또는 클라이언트 액세스 서버 배열에 대한 조회를 제공합니다. 끝점이 클라이언트 액세스 서버 또는 클라이언트 액세스 서버 배열에 있는 경우 개인 폴더 로그온만 허용하며 공용 폴더 액세스의 사서함 서버에 조회를 제공합니다.

Exchange 2007과 Exchange 2010 간의 클라이언트 연결에서의 차이점

RPC 클라이언트 액세스 서비스의 장점

RPC 클라이언트 액세스 서비스에 대한 여러 가지 장점이 있습니다. 모든 연결이 클라이언트 액세스 서버를 통해 설정되기 때문에 사서함 장애 조치(failover) 중에 클라이언트의 가동 중지 시간이 줄어듭니다. 장애 조치(failover)가 Exchange 2007에서 발생하면 네트워크 구성에 따라 다른 시간 동안 Outlook 클라이언트와 사서함 서버 사이의 연결이 끊어집니다. Exchange 2010에서 클라이언트 액세스 서버 배열에 있는 단일 클라이언트 액세스 서버에 오류가 발생하면 해당 클라이언트는 배열에 있는 다른 클라이언트 액세스 서버에 즉시 리디렉션됩니다. DAG(데이터베이스 가용성 그룹)의 일부인 사서함 서버가 실패하는 경우 장애 조치(failover) 데이터베이스를 탑재하는 데 걸리는 시간 동안에만 클라이언트의 연결이 끊깁니다.

부하가 분산된 클라이언트 액세스 서버 배열을 사용하여 배열의 모든 클라이언트 액세스 서버에서 트래픽 부하를 균등하게 분산시킬 수 있습니다.

이 새로운 아키텍처에서 해결된 다른 문제는 다음과 같습니다.

  • 다른 클라이언트에서 다르게 표시되는 메시지 관련 일부 문제

  • 전체 주소 목록에 인증서를 업로드하는 문제

  • 숨겨진 사용자에 대한 프로필을 만들 수 없음

  • 클라이언트에 일관되지 않은 비즈니스 논리 적용

  • 클라이언트 액세스 서버가 아닌 사서함 서버의 RPC 클라이언트 액세스 서비스에 연결하는 공용 폴더

또한 DSProxy 서비스가 제거되었으며 새 주소록 서비스가 인증서와 메일 그룹 구성원 업데이트 및 Outlook 클라이언트에 대한 위임 정보 유지 관리 작업을 수행합니다.

MAPI 클라이언트 연결

Exchange 2007에서 Outlook 및 기타 MAPI 클라이언트는 Exchange Web Services(가용성 서비스 및 부재 중 설정 포함) 및 오프라인 주소록 다운로드 등의 HTTPS 연결을 위해 클라이언트 액세스 서버와 통신했지만, 디렉터리 서비스 조사를 위해서는 사서함 서버의 MAPI RPC 구성 요소 및 글로벌 카탈로그 서버의 NSPI 끝점과 직접 통신했습니다.

Exchange 2010에서 이러한 연결은 클라이언트 액세스 서버 또는 클라이언트 액세스 서버 배열에 있는 MAPI RPC 연결점에 대해 이루어집니다.

주소록 서비스

이전 버전의 Exchange에서 NSPI(Name Service Provider Interface) 끝점을 찾는 Outlook 클라이언트를 알린 조회 서비스인 DSProxy에서 Outlook이 글로벌 카탈로그 서버로 향하도록 지정하는 작업을 수행합니다. DSProxy는 사서함 서버에 있었습니다. DSProxy는 Exchange 2010에서 제거되었으며 주소록 서비스로 바뀌었습니다.

현재 Outlook 클라이언트가 클라이언트 액세스 서버의 요청을 만들 때 두 가지 가능한 작업 중 하나가 수행됩니다.

  • 사용자의 사서함이 Exchange 2010 사서함 서버에 있으면 요청이 현재 Active Directory 사이트의 클라이언트 액세스 서버에서 처리되거나, 사용자의 사서함이 다른 Active Directory 사이트에 있으면 요청이 대상 Active Directory 사이트로 프록시 처리됩니다.

  • 사용자의 사서함이 레거시 Exchange 사서함 서버에 있으면 디렉터리 요청에 대해 사용자의 사서함 서버가 참조됩니다. 레거시 사서함 서버와 Exchange 2010 클라이언트 액세스 서버는 디렉터리 정보를 위한 통신을 직접 수행할 수 없습니다.

또한 주소록 서비스는 쓰기 가능한 도메인 컨트롤러 및 전체 주소 목록 액세스에 대한 정보를 제공합니다. 주소록 서비스에 대한 자세한 내용은 주소록 서비스 이해를 참조하십시오.

클라이언트 액세스 서버 배열

RPC 클라이언트 액세스 서비스 외에도 Exchange 2010은 Exchange 조직에 클라이언트 액세스 서버 배열이라는 새로운 논리 구조를 도입했습니다. 클라이언트 액세스 서버 배열이 Active Directory 사이트에서 정의된 경우 이 배열은 해당 Active Directory 사이트 내의 모든 클라이언트 연결에 대한 단일 연락처 역할을 합니다. 클라이언트 액세스 서버 배열에는 하나 이상의 클라이언트 액세스 서버가 포함될 수 있습니다.

클라이언트 액세스 서버 배열의 아키텍처

각 Active Directory 사이트에는 단일 클라이언트 액세스 서버 배열이 포함될 수 있습니다. 클라이언트 액세스 서버 배열은 부하 분산을 제공하지 않습니다. 별도의 부하 분산 솔루션이 필요합니다. 부하 분산에 대한 자세한 내용은 Exchange 2010의 부하 분산 이해를 참조하십시오.

조직에 단일 클라이언트 액세스만 있는 경우에도 클라이언트 액세스 서버 배열을 만드는 것이 좋습니다. 클라이언트 액세스 서버 배열이 만들어지면 클라이언트가 단일 클라이언트 액세스 서버의 FQDN(정규화된 도메인 이름)에 직접 연결하지 않고 가상 이름의 클라이언트 액세스 서버 배열을 통해 연결합니다. 단일 클라이언트 액세스 서버를 Active Directory 사이트 내에서 교체해야 하거나 두 번째 클라이언트 액세스 서버가 추가되는 경우 클라이언트에서 프로필 업데이트가 필요하지 않습니다.

클라이언트 액세스 서버 배열이 Active Directory 사이트 내에서 정의된 후, Active Directory 사이트 내의 모든 클라이언트 액세스 서버가 자동으로 클라이언트 액세스 서버 배열의 일부가 됩니다.

RPC 클라이언트 액세스 서비스 및 주소록 서비스 구성

RPC 클라이언트 액세스 서비스와 주소록 서비스를 구성하려면 다음 단계를 수행해야 합니다.

  1. 클라이언트 액세스 배열 만들기

  2. 부하 분산 구성

  3. IP 포트 구성

  4. RPC 암호화 설정 구성

  5. 사서함 데이터베이스 구성

  6. 적은 대기 시간 및 충분한 네트워크 속도 확인

클라이언트 액세스 배열 만들기

다음 명령을 사용하여 Active Directory 사이트 내에서 클라이언트 액세스 배열을 만들 수 있습니다.

New-ClientAccessArray -Name name -Site site_name -FQDN internal_only_CAS_Array_FQDN

참고

클라이언트 액세스 배열을 만든 후, DNS의 주소를 만들고 클라이언트 액세스 배열에 사용되는 가상 IP 주소에 이 주소를 연결해야 합니다.

내부에서 확인할 수 있는 명령에서만 (FQDN)을 지정하는 것이 중요합니다. 해당 이름을 외부에서도 확인할 수 있는 경우 이러한 외부 클라이언트는 HTTPS 대신 TCP 연결을 통해 해당 배열에 연결하려고 시도합니다.

부하 분산 구성

성능이 향상되도록 여러 서버에서 트래픽 부하 분산, 고가용성 및 장애 조치(failover)를 위한 부하 분산을 사용하는 것이 좋습니다. 부하 분산 솔루션을 선택할 때 다음 사항을 고려하십시오.

  • Windows 네트워크 부하 분산은 Windows 장애 조치(failover) 클러스터 서버에서 지원되지 않습니다.

  • 여러 Active Directory 사이트에서 클라이언트 액세스 배열을 사용할 수 없습니다. 대신 두 개의 클라이언트 액세스 배열을 만들고 해당 사이트 내에서 별도로 부하 분산을 수행합니다.

  • 하드웨어 부하 분산 장치는 일반적으로 반환 트래픽, 포트 가용성 또는 서비스 가용성을 모니터링하여 클라이언트 요청에 응답할 수 없는 서버에 네트워크 연결이 지정되지 않았는지 확인합니다.

  • ISA 2006 또는 TMG 2010 등의 일부 부하 분산 솔루션은 RPC 부하 분산을 수행할 수 없거나 RPC 서비스를 모니터링할 수 없습니다. 모든 클라이언트가 외부에서 Outlook 사용을 통해 연결되어 있고 모든 트래픽이 HTTP 내에서 캡슐화되지 않은 경우에는 이러한 솔루션이 권장되지 않습니다.

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

IP 포트 구성

IP 포트는 원래 컴퓨터에서 대상 컴퓨터로 정보가 전달될 수 있는 열린 포트입니다. 기본적으로 Windows Server 2008 R2의 나가는 연결에 대한 동적 포트 범위는 49152~65535입니다. Exchange 2010 클라이언트 액세스는 이 범위를 6005~65535으로 변경합니다. 이 범위는 대규모 배포를 위한 충분한 크기 조정을 제공합니다. 이는 클라이언트와 클라이언트 액세스 서버 또는 클라이언트 액세스 배열 사이의 방화벽을 통해 균형을 유지하기 위한 광범위한 포트입니다.

MAPI 및 디렉터리 끝점을 수정하면 부하 분산에 필요한 포트 수를 크게 줄일 수 있습니다. MAPI 끝점은 레지스트리에서 정적으로 구성할 수 있으며 디렉터리 끝점은 구성 파일에서 수정할 수 있습니다.

MAPI 끝점을 수정하려면 레지스트리에서 다음 설정을 사용합니다.

**HKLM\SYSTEM\CurrentControlSet\ Services\MSExchangeRPC\ParametersSystem\TCP/IP Port [DWORD]**는 사용할 IP 포트의 값입니다.

디렉터리 서비스 끝점을 수정하려면 레지스트리에서 RpcTcpPort 값을 편집합니다.

**HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeAB\Parameters\RpcTcpPort [String]**은 IP 포트에서 사용할 값입니다.

참고

외부에서 Outlook 사용 포트의 기본값은 수정하지 않는 것이 좋습니다.

RPC 암호화 설정 구성

RTM 버전의 Exchange 2010에서는 RPC 끝점이 기본적으로 암호화되어 있습니다. 그러나 Outlook 2003은 암호화된 MAPI 연결을 적용하지 않습니다. 조직을 RTM 버전의 Exchange 2010으로 업그레이드할 경우 Outlook 2007 이상 버전을 실행하는 클라이언트는 RPC 암호화를 기본적으로 지원하므로 변경된 RPC 클라이언트 액세스와 자동으로 호환됩니다. 하지만 Outlook 2003은 RPC 암호화를 사용하지 않으며 RPC 클라이언트 액세스에는 RPC 암호화가 기본적으로 필요합니다. 권장되지 않지만, RPC 암호화를 비활성화하지 않은 경우 사용자가 RPC 암호화를 사용하도록 Outlook 2003을 구성하거나 Outlook 2003에서 RPC 암호화를 사용하도록 그룹 정책을 사용해야 합니다.

이 문제의 증상에는 다음과 같은 오류 메시지가 포함됩니다.

  • Microsoft Office Outlook을 사용할 수 없습니다. Office 창을 열 수 없습니다. 폴더 집합을 열 수 없습니다.

  • 기본 전자 메일 폴더를 열 수 없습니다. 정보 저장소를 열 수 없습니다.

사용자가 캐시된 Exchange 모드를 사용하는 경우에는 Office가 오류를 표시하지 않고 연결되지 않은 모드로 시작됩니다.

기본적으로 Exchange 2010 SP1(서비스 팩 1)은 RPC 끝점을 암호화하지 않습니다. 조직에서 Exchange 2010 SP1 설치를 완료하지 않은 경우 추가 구성 없이도 Outlook 2003 클라이언트가 Exchange 서버에 연결할 수 있습니다.

이 문제에 대한 자세한 내용과 해결 방법은 Exchange 2010 사서함 Outlook 연결 문제를 참조하십시오.

Outlook 2003에서 RPC 암호화를 사용하도록 구성

Outlook 2003에서 RPC 암호화를 사용하도록 구성하려면 다음 단계를 사용합니다.

  1. 도구 > 전자 메일 계정 > 기존 계정 보기 또는 변경을 클릭합니다.

  2. 계정을 선택하고 기타 설정을 클릭합니다.

  3. 보안 탭을 선택합니다.

  4. Microsoft Office Outlook과 Microsoft Exchange Server 간의 데이터 암호화를 선택합니다.

  5. 확인을 클릭합니다.

사서함 데이터베이스 구성

각 사서함 데이터베이스에는 RPCClientAccessServer 값이 포함되어 있습니다. 이 값은 데이터베이스가 만들어질 때 설정되며 해당 사서함 서버의 사서함이 포함된 클라이언트가 사용하는 클라이언트 액세스 서버 또는 클라이언트 액세스 배열을 결정합니다. 이 값은 RPC 끝점 위치도 결정합니다. Outlook 2007 및 Outlook 2010 클라이언트의 경우, 이 값은 자동 검색 서비스에서 가져옵니다.

RPCClientAccessServer의 기본값은 다음 규칙에 따라 결정됩니다.

  • Active Directory 사이트 내에서 클라이언트 액세스 서버 배열을 구성한 경우 해당 배열의 주소가 사용됩니다.

  • Active Directory 사이트 내에 배열이 없고 동일한 실제 서버에 클라이언트 액세스 서버 역할 및 사서함 서버 역할 모두가 있는 경우 특정 사서함 서버에 대한 RPCClientAccessServer 속성 값은 사서함 서버와 동일합니다.

  • 그렇지 않은 경우 특정 사서함 서버에 대한 RPCClientAccessServer 속성 값은 Active Directory 사이트에서 임의의 클라이언트 액세스 서버로 설정됩니다.

    참고

    도메인 컨트롤러이기도 한 단일 컴퓨터에 모든 서버 역할을 설치하지 않는 것이 좋습니다. 이 구성은 사용 가능하지만 권장되지 않습니다.

  • Active Directory 사이트 내에서 클라이언트 액세스 배열이나 클라이언트 액세스 서버 설치 전에 사서함 데이터베이스를 만든 경우 RPCClientAccessServer 속성 값을 다시 구성해야 합니다. 사서함 데이터베이스를 만들 때 클라이언트 액세스 서버가 Active Directory 사이트에 있지 않은 경우 RPCClientAccessServer 속성 값인 사서함 서버의 FQDN으로 설정됩니다. RPCClientAccessServer 속성 값을 구성하려면 다음 명령을 사용합니다.

    Set-MailboxDatabase <name> -RPCClientAccessServer <internal_only_CAS_Array_FQDN>

대기 시간 및 대역폭 요구 사항

캐시된 Exchange 모드를 사용하지 않고 Outlook을 실행하는 사용자의 경우 클라이언트와 서버 간의 긴 대기 시간은 Outlook이 응답하지 않는 빈도에 영향을 줍니다. 일반적으로 홈 사서함 서버에 대한 200밀리초(ms) 이상의 대기 시간은 클라이언트 성능이 저하되게 합니다.

클라이언트 액세스 서버와 사서함 간의 대기 시간은 10ms여야 하기 때문에 활성 사서함 데이터베이스 사이트에서 RPCClientAccessServer 속성 값은 항상 클라이언트 액세스 배열로 구성하는 것이 좋습니다.

참고

RPCClientAccessServer 속성 값을 변경하면 모든 클라이언트가 강제로 다시 연결됩니다.

주소록 서비스 구성

주소록 서비스는 Microsoft.Exchange.AddressBook.Service.config 파일을 통해 구성합니다. 이 파일을 사용하여 다음을 구성할 수 있습니다.

  • 사용자당 동시 연결 수(기본 제한은 50)

  • 로깅을 사용하도록 설정하거나 사용하지 않도록 설정

  • 로그 파일의 위치, 크기 및 보존 기간

로깅을 사용하도록 설정하려면 다음 값을 사용합니다.

< add key="ProtocolLoggingEnabled" value="true" />

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