Communications

Microsoft의 Exchange Edge 전송 서버

Kay Unkroth

한 눈에 보기:

• Exchange Edge 전송 서버 역할
• 테스트 환경 설정
• 전송 에이전트 및 이벤트
• 에이전트 내부

이 기사의 코드 다운로드: ExchangeEdge2007_10.exe (354KB)

Microsoft에서는 업무일 기준으로 인터넷을 통해 하루 평균 약 1,300만 건의 메시지 전송 시도가 발생하고 있으며, 이 중에서 1,050만 건 이상의 합법적이지 않은 메시지가 차단됩니다.

인터넷에서 스팸 공격이 발생하거나 바이러스가 출현하는 등의 위험한 상황이 발생할 경우 합법적이지 않은 메시지의 수는 9,000만 건 이상으로 늘어날 수 있습니다. 물론 이 수치는 Microsoft를 기준으로 산출된 것이지만 온라인 사기, 스팸, 피싱, 전자 메일을 이용한 바이러스, 디렉터리 수집 공격, DDoS(분산 서비스 거부) 공격 등의 위협은 Microsoft만의 문제가 아닙니다. 이러한 상황에 직면할 경우 조직 내 사용자에게 합법적인 메시지는 모두 전달되도록 하면서 수많은 악의적이며 합법적이지 않은 콘텐츠가 조직의 메시징 환경에 침투하지 못하도록 하려면 어떻게 해야 할까요?

메시징 환경을 안정적으로 보호하는 한 가지 수단으로 인터넷과 조직의 프로덕션 환경 사이에 있는 경계 네트워크에 Exchange Server 2007 Edge 전송 서버와 Forefront Security for Exchange Server를 배포하는 방법이 있습니다. 이 경우 10개가 넘는 Edge 전송 에이전트가 경계 네트워크에 적절하게 배치되어 프로덕션 시스템과 사용자를 보호합니다. 불필요한 콘텐츠를 최대한 신속하게 차단할 때 얻게 되는 효과는 명백합니다. 위험한 상황이 발생할 경우 조직의 메시징 환경이 감당해야 하는 부하를 고려한다면 악의적인 콘텐츠가 서버로 유입되기 전에 이러한 보호 수단이 효력을 발휘하는 것이 가장 이상적입니다. 하지만 메시징 보호에는 단순히 메시지를 차단하는 것 이상의 많은 요소가 관련됩니다.

이 기사는 Exchange Server 2007과 Forefront Security for Exchange Server에서 사용할 수 있는 바이러스 및 스팸 방지 에이전트의 주요 기능과 아키텍처에 대해 다루는 2부 연재 기사 중 1부입니다. 실질적이고 실용적인 설명을 위해 1부 기사에서는 Microsoft가 자사의 프로덕션 환경에서 사용하는 메시징 보호 디자인이 반영되도록 테스트 환경을 설정하는 방법을 살펴본 다음, Exchange Server 2007의 Edge 전송 아키텍처에 대해 자세히 설명하겠습니다.

이 기사에서는 대부분의 중요 구성 작업을 자동화하기 위해 많은 스크립트와 배치 파일을 사용합니다. 이러한 파일에는 수행되는 개별 단계에 대해 설명하는 주석이 포함되어 있습니다. 스크립트는 TechNet Magazine 웹 사이트(technetmagazine.com/code07.aspx)에서 다운로드할 수 있습니다.

Edge 전송 토폴로지

그림 1에서는 Microsoft IT 팀이 회사 프로덕션 환경에 구현해 놓은 Edge 전송 디자인을 보여 줍니다. 여기에는 매우 흥미로운 디자인상의 몇 가지 특징이 있는데 먼저 이들에 대해 살펴본 다음 Edge 전송 아키텍처에 대해 설명하겠습니다. 구현 세부 사항에 대한 자세한 내용은 "Exchange 리소스" 추가 기사에 나오는 IT Showcase 백서를 참조하십시오.

그림 1** Microsoft의 Edge 전송 토폴로지 **(더 크게 보려면 이미지를 클릭하십시오.)

그림 1을 자세히 보면 Microsoft의 Edge 전송 토폴로지가 완전하게 중복되어 단일 장애 지점이 발생할 수 있는 곳이 한 군데도 없음을 알 수 있습니다. 부하 분산을 위해 Microsoft IT 팀에서는 외부적으로는 DNS 라운드 로빈을 사용하고 내부적으로는 여러 개의 브리지헤드가 있는 메시징 커넥터를 사용합니다. 또한 허브 전송 및 Edge 전송을 비롯한 모든 전송 서버에서는 바이러스 검사를 위해 Forefront Security for Exchange Server를 실행하고 있다는 점도 눈여겨보십시오. 이를 통해 Microsoft IT 팀은 인바운드, 아웃바운드, 내부 메시지 등의 모든 메시지가 메시지 라우팅 토폴로지의 전송 서버에 도달하면 곧바로 이를 검사할 수 있습니다.

보안과 관련된 또 한 가지 중요한 특징은 Edge 전송 서버가 회사 Active Directory® 환경에 포함되지 않는다는 점입니다. 사실 어떠한 Active Directory 포리스트에도 Edge 전송 서버를 배포할 필요는 없습니다. 하지만 일관된 관리 프레임워크를 유지하고, 공통된 정책 집합을 적용하며, Single Sign-On을 지원하기 위해 Microsoft IT 팀에서는 프로덕션 환경과는 별도의 엑스트라넷 포리스트에 모든 Edge 전송 서버를 배포했습니다.

마지막으로, 인터넷을 통해 들어오는 모든 메시지는 북미 지역에 있는 Edge 전송 서버를 통해 Microsoft에 도달한다는 것을 알 수 있습니다. 더블린과 싱가포르에 있는 Edge 전송 서버는 아웃바운드 메시지만 처리합니다. 이렇게 모든 인바운드 트래픽을 북미에 있는 Edge 전송 서버에서 처리하도록 하면 보안 및 스팸 방지 작업을 중앙 집중화하는 동시에 아웃바운드 메시지가 지역별 주요 데이터 센터에서 내부 메시징 백본을 경유하여 전송되는 것을 방지하는 효과를 얻을 수 있습니다.

Microsoft의 Edge 전송 토폴로지는 Microsoft IT 팀의 시스템 엔지니어인 Omesh Desai가 디자인했습니다. Omesh에게 이 디자인의 가장 중요한 특징이 무엇인지 물었는데 이렇게 답했습니다. "이 Edge 전송 디자인에서는 메시징 보호를 위해 메시징 백본의 여러 계층에서 Exchange의 기본 스팸 방지 및 바이러스 백신 기능을 사용합니다. 메시징 경계의 보안을 최우선적으로 고려하였지만 단순한 관리 및 유지 모델 또한 매우 중요했습니다. Edge 전송 서버를 사용함으로써 방화벽을 보다 강력하게 구성하여 보안을 강화하는 동시에 IP 신뢰도 서비스, 콘텐츠 필터 자동 업데이트, Safelist Aggregation, 전자 메일 소인 유효성 검사 등을 통해 스팸을 보다 정확하게 필터링할 수 있게 되었습니다. 내부에서 이루어지는 모든 서버 간 통신은 기본적으로 암호화되며 가능한 경우에는 외부 대상과의 통신도 암호화됩니다.

Edge 전송 서버에는 두 개의 듀얼 코어 64비트 프로세서와 8GB의 메모리를 사용하고 있습니다. 이러한 서버 여섯 대를 두 곳의 데이터 센터에 설치하여 부하를 분산시킴으로써, 인터넷에서 바이러스가 출현하는 등의 위험한 상황이 발생할 경우 메시지 전송량이 급격히 증가하더라도 충분히 대응할 수 있게 되었습니다."

Edge 전송 테스트 환경

테스트 환경 설정

존재하지 않는 도메인 이름과 개인 IP 주소를 사용하는 것이 가장 좋으므로 여기에서는 AdventureWorks.com과 192.168.xxx.0-24 범위의 IP 주소를 사용하겠습니다. 지금은 부하 분산이나 내결함성을 테스트하는 것이 아니므로 중복 시스템이나 방화벽 배열은 사용하지 않겠습니다. 물론 Microsoft IT 팀에서 사용하는 실제 방화벽 시스템에 대해서는 보안상의 이유로 설명할 수도 없습니다. 어쨌든 이 테스트 환경에서는 이러한 세부적인 사항은 중요하지 않습니다.

이 테스트 환경에서는 Exchange Server 2007에 가장 일반적으로 사용되는 방화벽 시스템 중 하나인 ISA Server 2006을 사용합니다. 외부 및 내부 방화벽 모두에서 ISA Server 2006을 실행하면 테스트 환경의 복잡함을 적정 수준으로 유지할 수 있어서 좋지만 프로덕션 환경에서는 다양한 내부 및 외부 방화벽 시스템을 통해 보안을 강화하는 것이 좋습니다. IPsec(IP 보안) 정책을 배포하거나 TLS(전송 계층 보안) 환경을 준비하는 것은 이 기사의 범위를 벗어나는 것이므로 제외했습니다.

한편, 가상 컴퓨터와 32비트 평가용 소프트웨어를 사용했으며 이것은 Microsoft 웹 사이트에서 다운로드할 수 있습니다. Microsoft는 프로덕션 환경에서는 32비트 버전의 Exchange Server 2007을 지원하지 않지만 이것은 테스트 환경에서는 문제가 되지 않습니다.

이 테스트 환경에서는 가능하면 기본 설정을 사용합니다. Exchange Server 2007 설치 프로그램을 실행하고 Edge 전송 서버를 프로덕션 환경에 추가하기 전에 IP 구성, 방화벽 및 DNS 영역에만 세심한 주의를 기울이면 됩니다. IP 구성과 관련한 자세한 내용은 함께 다운로드할 수 있는 Test Lab—IP Configuration.xls 파일을 참조하십시오. 동일한 IP 주소 할당 방법을 사용하는 경우 ISA01 컴퓨터에서 직접 ISA01_Firewall_Policies.vbs 스크립트를 실행하여 외부 방화벽(ISA01)을 빠르게 구성할 수 있으며 내부 방화벽(ISA02)에는 ISA02_Firewall_Policies.vbs를 사용할 수 있습니다. 함께 다운로드할 수 있는 파일에는 DNS 서버를 구성하는 데 사용되는 배치 파일(INTERNET01_DNS_Config.bat, AD01_DNS_Config.bat 및 AD02_DNS_Config.bat)도 포함되어 있습니다. 이러한 배치 파일은 DNS 명령줄 도구(dnscmd.exe)를 사용하므로 Windows 지원 도구가 설치되어 있어야 하며, 설치되어 있지 않으면 DNS 콘솔을 사용하여 직접 DNS 레코드를 만들어야 합니다.

기존 환경으로부터의 간섭을 피하기 위해 이 테스트 환경은 인터넷에 연결되어 있지 않습니다. 인터넷으로부터 격리하는 것은 좋은 예방책입니다. 이로 인해 서명 업데이트, IP 신뢰도, 콘텐츠 필터 업데이트가 다운로드되지 않지만 테스트 환경에서는 이러한 업데이트가 중요하지 않으므로 상관없습니다. 오류 메시지가 나타나지 않도록 하려면 Forefront Server Security Administrator 콘솔의 검색 프로그램 업데이트로 이동하여 모든 검색 프로그램의 업데이트 빈도를 한 번으로 설정한 다음 날짜를 과거의 날짜로 지정하면 됩니다.

이러한 기능이 실제로 어떻게 작동하는지 살펴보려면 테스트 환경을 만드는 것이 좋습니다. 프로덕션 시스템을 직접 테스트에 사용하지 않아야 한다는 것은 상식이라고 할 수 있습니다. 최소 구성의 경우 사서함, 클라이언트 액세스, 허브 전송 서버 역할을 위해 Exchange Server 2007을 실행하는 한 대의 서버가 있어야 합니다. Edge 전송 서버 역할에는 또 다른 Exchange 서버가 필요합니다. 허브 전송 서버의 %ProgramFiles%\Microsoft\Exchange Server\Scripts 폴더에 있는 Install-AntispamAgents.ps1 스크립트를 실행하여 모든 전송 에이전트를 다중 역할 서버에 배포하는 경우에는 Edge 전송 서버 설치를 생략할 수 있습니다. 하지만 이 방법은 Microsoft IT 팀이 배포한 방법과는 유사한 점이 거의 없습니다. 테스트 환경을 좀 더 현실적으로 구성하려면 몇 대의 서버를 더 추가해야 합니다. 그림 2에서는 필자가 이 기사를 작성하는 데 사용한 테스트 환경을 보여 줍니다. 보다 자세한 그림은 함께 다운로드할 수 있는 파일에 포함되어 있습니다. 테스트 환경 설정에 대한 자세한 내용은 "테스트 환경 설정" 추가 기사를 참조하십시오.

그림 2** Edge 전송 테스트 환경 **(더 크게 보려면 이미지를 클릭하십시오.)

Edge 전송 서버를 구독하고 관련 커넥터를 구성하는 동안 Microsoft IT 팀은 기본 커넥터를 모두 제거한 다음 각기 다른 종류의 SMTP(Simple Mail Transfer Protocol) 호스트 및 내부 허브 전송 서버와의 효율적인 통신을 위해 4개의 송신 커넥터를 만들었습니다. 첫 번째 송신 커넥터는 특정 주소 공간 정의와 일치하지 않는 모든 대상에 사용되는 일반 인터넷 커넥터입니다.

두 번째 송신 커넥터는 확장 SMTP를 지원하지 않는 알려진 대상(HELO 도메인)을 위한 세부 주소 공간 정의가 있는 인터넷 커넥터입니다. Microsoft IT 팀은 이 커넥터의 ForceHELO 매개 변수를 $true로 설정함으로써 SMTP 연결을 설정할 때는 불필요한 EHLO, 실패 응답 500, HELO 단계를 건너뜁니다.

세 번째 송신 커넥터는 암호화된 연결을 통한 보안 통신을 위해 TLS를 지원하는 파트너 및 다른 원격 도메인(TLS 도메인)을 위한 세부 주소 공간 정의가 있는 인터넷 커넥터입니다. 이 커넥터의 RequireTLS 매개 변수는 $true로 설정되어 있습니다.

네 번째 송신 커넥터는 수신한 인터넷 메시지를 회사 환경 내의 허브 전송 서버로 전송하기 위한 인바운드 커넥터입니다. Edge 전송 서버 구성에 대한 자세한 내용은 이 기사의 뒷부분에 있는 "Exchange 리소스" 추가 기사에 나오는 IT Showcase 백서를 참조하십시오.

Microsoft IT 팀에서 사용한 것과 비슷한 커넥터 토폴로지를 테스트 환경에 적용하기 위해 필자는 Omesh가 Microsoft IT 내부용으로 만든 스크립트에 바탕을 두는 절차를 따랐습니다. 보안상의 이유로 개별 명령들을 대폭 바꾸고 간소화했지만 결과적으로 만들어지는 커넥터 토폴로지는 Microsoft IT 토폴로지와 같습니다. 단계는 다음과 같습니다.

1. 다중 역할 Exchange 서버(HUB-MBX-01)와 Edge 전송 서버(EDGE01)에서 기본 커넥터를 제거합니다.
2. HUB-MBX-01에서 이 기사의 다운로드에 있는 HUB-MBX-01_recv_connector.ps1 스크립트를 실행하여 새 수신 커넥터를 만듭니다.
3. EDGE01에서 EDGE01_recv_connector.ps1 스크립트를 실행하여 내부 및 외부 메시징 연결에 사용할 두 개의 새 수신 커넥터를 만듭니다.
4. EDGE01에서 다음 명령을 실행하여 구독 파일을 만듭니다.

    New-EdgeSubscription -FileName 
    "c:\subscriptionfile.xml" 

그런 다음 만들어진 구독 파일을 허브 전송 서버의 루트 폴더(c:\subscriptionfile.xml)에 복사합니다.

5. HUB-MBX-01에서 구독 파일의 경로가 c:\subscriptionfile.xml인지 확인한 다음 HUB-MBX-01_complete_subscription.ps1 스크립트를 실행합니다. 이 스크립트는 송신 커넥터를 자동으로 만들지 않고 Edge 동기화를 위해 구독 파일을 가져오고, 인터넷 및 내부 연결에 사용할 송신 커넥터를 만들고, 결과적으로 생성되는 구성을 Edge 동기화를 통해 Edge 전송 서버에 복제합니다.

6. Contoso.User@contoso.com 및 Fabrikam.User@fabrikam.com을 보낸 사람으로 하여 인터넷 호스트에서 Administrator@adventureworks.com으로 테스트 메시지를 보낸 다음 받은 메시지에 대해 회신을 함으로써 인바운드 및 아웃바운드 메시지 전송이 작동하는지 확인합니다.

개별 스크립트 파일을 메모장에서 열어 이러한 스크립트가 구성 작업을 수행하는 데 사용하는 cmdlet와 매개 변수를 분석해 보는 것이 좋습니다. cmdlet 및 매개 변수에 대한 자세한 내용은 Exchange Server 2007 제품 설명서에서 온라인으로 확인할 수 있습니다.

Edge 전송 아키텍처

이제 Edge 전송 서버 역할을 설치한 이후 누군가가 HELO나 EHLO라고 말할 때까지 기다려 온 Edge 전송 에이전트에 대해 살펴보겠습니다. Edge 전송 서버에서 Get-TransportAgent cmdlet를 실행하면 그림 3에 나오는 11개의 항목이 표시됩니다. 모든 에이전트는 기본적으로 활성화되어 적절한 설정을 통해 메시징 보호 기능을 제공합니다.

Figure 3 전송 에이전트

Get-TransportAgent cmdlet와 그림 3에서는 에이전트를 우선 순위별로 보여 주지만 이 순서가 에이전트의 작업 수행 순서는 아닙니다. 작업 순서는 주로 SMTP 수신 이벤트 및 라우팅 이벤트에 대해 에이전트가 등록된 순서에 따라 달라집니다. 에이전트와 이벤트의 상호 작용 방법을 보려면 전송 에이전트가 Edge 전송 아키텍처에 통합되는 방법을 보여 주는 그림 4의 다이어그램을 참조하십시오.

그림 4** Edge 전송 아키텍처 내의 전송 에이전트 **(더 크게 보려면 이미지를 클릭하십시오.)

전송 이벤트는 스팸 필터링, 바이러스 검사 및 기타 작업을 위한 추가 코드를 호출하기 위해 메시지 처리 중 여러 단계에서 발생합니다. 이렇게 느슨하게 연결되고 확장 가능한 디자인에서는 Edge 전송 프로세스(EdgeTransport.exe)가 이벤트 원본 역할을 합니다. 이벤트 처리기, 즉 전송 에이전트는 콜백 알림을 받기 위해 이벤트 원본에 등록하는 Microsoft® .NET Framework 2.0 기반의 관리되는 대리자 개체입니다.

그림 5에서는 Forefront Security와 함께 Edge 전송 서버에 설치된 모든 에이전트에 대한 이벤트 등록을 보여 줍니다. 등록된 에이전트 수가 많기 때문에 이를 분류하기는 다소 어렵지만 걱정할 필요는 없습니다. Edge 전송 서버에서 Get-TransportPipeline | Format-List 명령을 실행하면 개별 전송 이벤트에 대한 등록을 간편하게 분석할 수 있습니다. Microsoft Exchange Transport 서비스(MSExchangeTransport.exe)가 실행 중인지 확인하고 서비스를 마지막으로 다시 시작한 이후 Edge 전송 서버를 통해 한 개 이상의 메시지를 전송했는지 확인하면 됩니다. 출력에서 볼 수 있듯이 여러 에이전트가 동일한 이벤트 유형에 등록하거나 개별 에이전트가 여러 이벤트에 등록할 수 있습니다. 이벤트 등록은 해당 에이전트의 처리 요구 사항에 따라 다릅니다.

그림 5** 전송 에이전트에 대한 이벤트 등록 **(더 크게 보려면 이미지를 클릭하십시오.)

가장 중요한 이벤트 중 하나는 메시지가 전송 큐에 도착할 때 트리거되는 OnSubmittedMessage 라우팅 이벤트입니다. SMTP, 파일 시스템 또는 다른 어떤 메커니즘을 통해 들어오는 메시지도 모두 이 큐를 통과해야 합니다. 분류기는 받는 사람 확인, 메시지 분기 및 라우팅, DSN(배달 상태 알림) 생성을 담당하는 Exchange Server 전송 아키텍처의 핵심 구성 요소입니다. 따라서 OnSubmittedMessage 이벤트는 받은 메시지를 모두 처리해야 하는 에이전트를 위한 최적의 등록 옵션입니다. FSE 라우팅 에이전트는 받은 모든 메시지를 바이러스 검사 엔진에 전달하기 위해 OnSubmittedMessage 이벤트에 등록된 Forefront Security 구성 요소입니다. FSE 라우팅 에이전트는 OnSubmittedMessage 이벤트에 등록되어 있으므로 어떤 메시지도 바이러스 백신 솔루션을 우회할 수 없습니다.

그렇다면 모든 에이전트가 OnSubmittedMessage 이벤트에 등록하면 되는데 그렇게 하지 않는 이유는 무엇일까요? 이는 불필요한 메시지를 가능한 한 신속하게, 즉 서버에서 성공적 배달을 확인하기 전에 차단하기 위해서입니다. 가능한 한 신속하게 차단하지 못하는 경우 스팸 또는 바이러스 공격이 감행되는 동안 서버에서 9,000만 개의 불필요한 메시지를 처리해야 하고 9,000만 개의 NDR(배달 못 함 보고서)을 생성해야 할 수도 있는데 이는 순진한 방관자에게는 심각한 위협이 될 수 있습니다. 스팸 및 바이러스 공격은 항상 위조된 보낸 사람 정보를 사용합니다. 원래 메시지를 만들지 않은 받는 사람에게 수백만 개의 NDR을 보내는 경우 사용자 조직의 리소스와 함께 대상 조직의 리소스가 낭비될 뿐만 아니라 악의적 사용자에게 메일 폭탄 및 DDoS 공격을 실행할 빌미를 주게 됩니다. 자신의 조직은 물론 다른 사용자의 조직을 보호하기 위해서는 악의적인 보낸 사람의 행위를 도중에 차단하는 것이 중요합니다.

메시지를 효율적으로 차단하려면 서버에서 250 OK라는 상태 코드가 있는 데이터의 수신을 확인하기 전에 전송 에이전트가 원격 호스트와의 SMTP 대화를 중단시켜야 합니다. SMTP 축적 전송 원칙에 따라 서버에서는 메시지 배달이 확인되지 않은 경우 NDR을 생성하지 않고도 받은 데이터를 안전하게 삭제할 수 있습니다. SMTP 수신 에이전트가 이 작업을 수행할 수 있습니다. SMTP 수신 에이전트는 SMTP 세션과 상호 작용하는데 이는 원격 호스트가 서버에 연결할 때 전송 파이프라인이 SMTP 수신 이벤트를 기반으로 이러한 에이전트를 호출하고, SMTP 세션을 설정하고, SMTP 동사를 전송하고, 메시지를 전송하고, 연결을 종료하기 때문입니다. 각 단계와 관련된 SMTP 수신 이벤트는 그림 6에 나옵니다. 모든 Exchange Server 2007 스팸 방지 에이전트는 메시지가 배달되기 전에 메시지를 거부하고 원격 SMTP 호스트에서 연결을 끊을 수 있으므로 SMTP 수신 에이전트로 구현됩니다.

Figure 6 SMTP 세션 이벤트

처리 컨텍스트와 관련하여 SMTP 수신 에이전트와 라우팅 에이전트의 차이점을 올바르게 이해하는 것이 중요합니다. 라우팅 에이전트는 메시지 속성에 대한 모든 권한을 갖는 반면 SMTP 수신 에이전트는 SMTP 세션과 상호 작용하므로 컨텍스트와 보다 밀접하게 관련됩니다. 예를 들어 원격 호스트가 실제로 메시지를 전송하기 전까지는 메시지 속성에 대해 스팸 필터가 작동할 수 없습니다. 따라서 에이전트를 올바른 SMTP 수신 이벤트에 등록하는 것이 중요합니다. 자세한 내용은 "전송 에이전트 개발" 추가 기사를 참조하십시오.

Exchange 리소스

• Microsoft Exchange Server 2007 Edge 전송 및 메시징 보호(Microsoft IT Showcase 기술 백서)
• Windows PowerShell 스크립트 센터
• Exchange Server 2007 TechCenter
• Microsoft Exchange 팀 블로그 "You Had Me From EHLO"

계속

전송 아키텍처 및 테스트 시나리오에 대해서는 다음 기사에서 자세히 살펴보도록 하겠습니다. 이 기사에서는 Microsoft IT 팀에서 수행한 것과 유사한 방식의 Edge 전송 서버 배포부터 메시지 처리 중 전송 파이프라인에서 트리거되는 내부 이벤트에 이르는 다양한 부분에 대해 다루었습니다. 2부에서는 몇 가지 흥미로운 테스트 시나리오를 통해 Edge 전송 에이전트의 동작을 분석해보도록 하겠습니다.

90일 무료 평가판인 Microsoft Visual Studio 2005 Professional Edition(go.microsoft.com/fwlink/?LinkId=98043)을 다운로드한 다음 Steve의 설명에 따라 테스트 환경에 샘플 에이전트를 컴파일하고 설치해 보십시오. 개발자가 아니더라도 이러한 작업을 수행하는 것은 매우 간단합니다. Visual Studio 2005를 사용하여 Exchange Server 2007에서 이러한 구성 요소를 개발하는 것이 얼마나 편리한지 감안한다면 사용자 지정 에이전트에 의존하는 비즈니스 응용 프로그램의 수가 급증하고 있다는 것이 그다지 놀라운 일은 아닙니다.

Kay Unkroth는 15년 이상 Microsoft 서버 기술 분야에서 기술 지원 엔지니어, 시스템 개발자, 컨설턴트, 강사 및 저술가로 활동하고 있으며, 문서화 및 지역화 관리 서비스를 전문적으로 제공하는 회사인 Biblioso Corporation의 공동 창업자이자 회장입니다.

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