Exchange Queue & AOutlook Anywhere와 IPv6, Remote Connectivity Analyzer 및 기타 정보
Henrik Walther
Q: 우리 회사에서는 최근에 Windows Server 2008 기반 서버에 Exchange 2007 배포를 완료했습니다. 다른 부분은 잘 작동하는데 한 가지 문제가 있습니다. Microsoft TechNet의 Exchange 2007 설명서에 있는 지침에 맞게 Outlook Anywhere(이전의 RPC over HTTP)를 구성했지만 아무리 해도 인터넷상의 Outlook 2007 클라이언트에서 Exchange 2007 클라이언트 액세스 서버에 연결할 수 없습니다. 클라이언트에서 SAN 인증서가 신뢰되는지 확인했고 클라이언트 액세스 서버와 연결된 방화벽에서 TCP 포트 443이 열려 있는지도 확인했습니다. 이러한 유형의 문제를 본 적이 있습니까?
A: 예, 이러한 현상을 경험한 적이 있습니다. Windows Server 2008 기반 서버에 Exchange 2007을 설치했다고 하셨는데 Windows Server 2008 서버에 클라이언트 액세스 서버를 설치된 경우 해당 서버에 IPv6이 활성화되어 있으면 Outlook Anywhere가 제대로 작동하지 않습니다. Windows Server 2008에 Exchange 2007 SP1을 설치하면 Exchange 2007 SP1이 기본적으로 활성화되므로 이를 비활성화해야 합니다. 이렇게 문제를 해결한 경우를 몇 번 보았습니다.
Windows Server 2008에서 Outlook Anywhere와 IPv6이 문제를 일으키는 이유와 Windows 2008 서버에서 Exchange 2007에 영향을 주지 않고 올바르게 IPv6을 비활성화하는 방법에 대한 자세한 내용은 msexchangeteam.com/archive/2008/06/20/449053.aspx에 있는 Microsoft Exchange 팀의 블로그 포스트를 참조하십시오. Exchange 2007 SP1 Rollup 4에서는 이 문제가 해결될 것입니다.
Q: 현재 Exchange 2007 기반 메시징 환경에서 Outlook Anywhere와 Exchange ActiveSync를 구현하고 있습니다. 현재 우리의 경계 네트워크 외부에서 Outlook Anywhere가 예상대로 작동하는지 테스트하는 방법이 있는지 알고 싶습니다. 그리고 환경에 자동 검색 서비스가 올바르게 구성되었는지 확인하고 싶습니다. 방법이 있을까요?
A: 예, Outlook Anywhere가 올바르게 작동하는지 테스트하는 방법이 있습니다. 두 명의 Microsoft 직원(Exchange 제품 그룹의 Shawn McGrath와 제품 지원 서비스의 Brad Hughes)이 ExRCA(Exchange Server Remote Connectivity Analyzer)라는 도구를 개발했습니다. 이 도구는 아직 프로토타입 상태이지만 사용하는 데 문제가 될 만한 문제는 없습니다. 이 도구를 사용하여 Outlook 2007 자동 검색 및 RPC/HTTP 연결 테스트를 수행하고, Exchange ActiveSync와 인바운드 SMTP 메일 흐름이 예상대로 작동하는지 확인할 수 있습니다. ExRCA는 아직 Microsoft가 지원하는 도구는 아니지만 Exchange 2007에 대한 모든 원격 테스트에 상당히 유용합니다.
그림 1 Exchange Server Remote Connectivity Analyzer 시작 페이지 (더 크게 보려면 이미지를 클릭하십시오.)
Q: 우리 회사에서는 Exchange Server 2007을 사용하고 있으며 현재는 SCR(대기 연속 복제) 배포를 준비하는 단계입니다. 우리 회사에서 원하는 것은 각 사서함 데이터베이스의 데이터 복사본을 다른 사이트에 있는 비클러스터형 사서함 서버에 저장하는 것입니다. Microsoft TechNet에 있는 Exchange 2007 설명서에서 SCR에 대한 내용을 충분히 읽어 보았지만 아직 확인할 수 없는 사항이 있습니다. SCR 대상을 활성화하면 특정 사서함 데이터베이스의 모든 사용자 사서함에 대해 –ConfigurationOnly 매개 변수만 지정하고 Move-Mailbox를 수행한 것과 같은 효과가 있습니까? 다른 말로 하면 Active Directory의 Exchange 서버 위치만 변경하는 것인지 궁금합니다.
A: 원본 SCR 서버로 비클러스터형 사서함 서버를 사용하는 것이므로 말씀하시는 내용이 맞습니다. 다른 서버에서 SCR 복사본을 활성화하는 것이므로 데이터베이스 이식성이 사용됩니다. 이것은 해당 사서함 데이터베이스에서 사용자 사서함의 Active Directory 내 Exchange 서버 위치가 변경된다는 것을 의미합니다.
사용자의 Exchange 2007 환경에서 원본 SCR 서버가 CCR(클러스터 연속 복제)이나 SCC(단일 복사본 클러스터) 기반이며 장애 조치(failover) 클러스터에서 패시브 노드를 SCR 대상으로 사용한 경우에는 SCR 대상을 동일한 이름으로 활성화하며 Active Directory의 Exchange Server 서버 위치가 변경되지 않을 것입니다.
Q: 우리 회사에서는 최근 Exchange Server 2007 배포를 완료했습니다. 포리스트와 도메인이 Exchange 2007을 설치할 준비가 되었을 때 Exchange 2007 설치 프로그램이 생성하는 6개의 Exchange 2007 보안 그룹을 루트 도메인에 생성되는 Microsoft Exchange Security Groups OU 대신 다른 조직 구성 단위로 옮기는 작업이 지원되는지 궁금합니다.
A Exchange 2000/2003은 Exchange 그룹을 포리스트 내의 다른 OU로 옮기는 작업을 지원하지 않았지만 Exchange 2007은 이 작업을 지원합니다. 포리스트가 Exchange 2007에 맞게 준비되었을 때 생성되는 6개의 Exchange 2007 보안 그룹(그림 2 참조)에는 두 가지 고유 속성의 스탬프가 추가되는 것을 알 수 있습니다. 첫째는 잘 알려진 GUID이며 둘째는 변경될 수 있는 고유 이름입니다.
그림 2 Exchange Server 2007 보안 그룹 (더 크게 보려면 이미지를 클릭하십시오.)
이러한 두 속성이 있으며, 설치 프로그램이 실행될 때 해당 포리스트의 OtherWellKnownObjects 특성에 보안 그룹이 추가되므로 이러한 보안 그룹이 포리스트에 어디에 있든지 Exchange가 이들을 찾을 수 있습니다. 즉, 그룹을 포리스트의 다른 도메인을 포함하여 어디든지 원하는 곳으로 이동해도 됩니다. 추가 정보는 Microsoft TechNet에서 Exchange 2007 설명서에 포함되어 있는 Ross Smith의 훌륭한 Exchange 2007 사용 권한 FAQ(technet.microsoft.com/bb310792)를 참조하십시오.
Q: Exchange 2007 기반 메시징 환경의 구조를 약간 변경해야 할 필요가 생겨서 각 Exchange 2007 CCR 사서함 서버에 대한 파일 공유 감시를 다른 허브 전송 서버로 이동하려고 합니다. 이 작업을 지원되는 방식으로 수행하는 지침이 있을까요?
A: 파일 공유 감시를 Exchange 2007 허브 전송 서버에서 다른 허브 전송 서버로 이동하는 방법은 매우 간단합니다. 클러스터형 사서함 서버의 파일 공유 감시를 처음 구성할 때 수행했던 절차를 다시 수행하면 됩니다. 유일한 차이점은 서버에 지정하는 경로입니다. 이 작업을 위한 단계는 Microsoft TechNet에 있는 Exchange 2007 설명서에서 파일 공유 감시를 구성하는 방법(technet.microsoft.com/bb124922)을 참조하십시오.
파일 공유 감시를 구성할 때 CNAME 레코드를 사용하여 허브 전송 서버를 지정한 경우에는 대상 호스트의 FQDN(정규화된 도메인 이름)을 해당 CNAME 레코드의 별칭이 가리키는 항목으로 변경하기만 하면 됩니다(그림 3 참조).
그림 3 파일 공유 감시의 대상 호스트를 가리키는 CNAME 레코드 (더 크게 보려면 이미지를 클릭하십시오.)
클러스터 노드가 다른 사이트에 있는 경우에 대한 Exchange 제품 그룹의 사이트 복구 지침(msexchangeteam.com/archive/2008/04/03/448615.aspx 참조)이 변경되었으므로 주의하십시오. 기본적으로 Exchange 제품 그룹에서는 지리적으로 분산된 Exchange 2007 환경에 CNAME 레코드를 사용하는 것을 권장하지 않습니다.
Q: 현재 회사에서 사용 중인 Exchange 2007 메시징 서버의 보안 설정을 개선하는 계획을 수립하고 있습니다. 보안 최적화 계획 중에는 Exchange 데이터베이스가 있는 볼륨을 암호화하는 것이 포함되어 있습니다. EFS(파일 시스템 암호화) 암호화를 사용하여 암호화된 볼륨에 Exchange 데이터베이스 파일을 저장하는 것이 지원되는지 그리고 지원된다면 이것이 권장되는지 궁금합니다.
A: 불가능합니다. Microsoft는 Exchange 2007 데이터베이스를 EFS 기반 암호화 볼륨에 저장하는 것을 지원하지 않습니다. 실제로 .edb, .log, .stm(Exchange 2000/2003), .dat, .eml 및 .chk 파일에 대해서도 지원하지 않습니다. 가장 중요한 이유는 암호화에 따라 추가 오버헤드가 발생하여 성능이 크게 저하되기 때문입니다.
Exchange 2007 데이터 파일을 추가로 보호하고자 한다면 Exchange 컴퓨터에 대한 무단 액세스를 방지하고 S/MIME 메시지 형식을 사용하여 메시지 데이터를 암호화하십시오. Windows Server 2008에서 Exchange 2007을 사용하는 경우에는 BitLocker를 사용하여 볼륨을 보호하는 방법도 고려해 볼 수 있습니다.
Q 도메인 컨트롤러 역할도 수행하는 Windows Server 2008 서버에 최근 Exchange 2007 SP1 설치를 완료했습니다. 이 환경에는 IPv6이 사용되지 않으므로 Exchange 2007 SP1을 설치한 다음 네트워크 연결에서 이 옵션을 비활성화하고 서버를 다시 부팅했습니다. 그런데 다시 온라인 상태가 되자 Exchange 2007 서비스가 시작되지 않았습니다. 응용 프로그램 로그에는 오류 214와 함께 다음과 같은 정보가 포함되어 있었습니다.
Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=1712). Topology discovery failed, error 0x80040a02 (DSC_E_NO_SUITABLE_CDC).
A: 이러한 현상에 대한 보고를 몇 차례 받은 적이 있습니다. 도메인 컨트롤러 역할을 수행하는 Windows Server 2008 서버에 Exchange 2007 서버 역할을 설치하는 것은 그리 바람직하지 않지만 IPv6을 비활성화한 상태에서 도메인 컨트롤러에서 하나 이상의 Exchange 2007 서버 역할을 실행하는 경우에는 작동하는 것이 일반적입니다. 특히 테스트 환경에서는 이러한 설정이 일반적입니다. 해결책은 서버에서 IPv6을 다시 활성화하는 것입니다. Exchange 2007 SP1 Rollup 4에서는 이 문제가 해결된다는 이야기가 있습니다.
Henrik Walther는 Microsoft Certified Master로서, 14년 이상의 IT 비즈니스 경력을 자랑하는 Exchange 2007 및 Exchange MVP이기도 합니다. 현재 Interprise Consulting(덴마크에 위치한 Microsoft 인프라 골드 파트너)에서 기술 설계자로 근무하면서 Biblioso Corp(미극에 위치한 문서 관리 및 지역화 서비스를 전문 업체)에서 테크니컬 라이터로도 활동하고 있습니다.