Exchange Queue & A우리는 모든 답을 알고 있어요. 바로 우리가 질문한 거거든요.

KC Lemson and Paul Bowden

안녕하세요. 이번 호부터 새롭게 게재되는 Exchange Queue & A입니다. 처음 소개할 질문들은 사실 우리가 직접 작성한 것이기 때문에 진정한 의미의 질문과 대답(Q&A) 칼럼으로 보기에는 다소 부족한 면이 있을 수도 있습니다.

우리 스스로 질문을 작성하고 그에 대해 대답하는 것은 고객이 진정으로 원하는 Q&A가 아닐 수도 있기 때문입니다. 하지만 우리는 이러한 질문들이 Microsoft® Exchange Server 고객들이 궁금해 하는 사항일 것이라고 믿기 때문에 교훈적 근거는 충분하다고 생각합니다. 물론 향후에는 고객들의 질문을 받을 것이므로 질문이 있으면 언제든지 queuea@microsoft.com으로 보내 주시기 바랍니다.

현재로서는 여러 작성자들이 돌아가면서 칼럼을 작성해 보도록 하려고 합니다. 그러니까 여러 작가들에게 질문과 답변을 작성하도록 해서 어떤 작가가 유용한 질문과 답변을 작성하는지 알아보려는 것이지요. 하지만 이들은 모두 수년간 Exchange와 관련된 업무를 해 왔습니다. 이 달의 답변(그리고 질문!)은 Microsoft의 Exchange 제품 팀에서 선임 프로그램 관리자로 일하고 있는 KC Lemson과 Paul Bowden이 공동으로 작성하였습니다. 우리 둘 모두 Exchange 개발에 있어서는 고참이라고 할 수 있습니다. 우리는 이곳저곳을 상당히 많이 돌아다녔지만 메시징에서 벗어날 수 있었던 적은 한 번도 없었습니다.

KC는 지난 6년간 Exchange 그룹에서 Microsoft Outlook® Web Access(OWA) 프로그램 관리자와 Exchange 시험판 고객 프로그램을 담당하는 선임 프로그램 관리자 등 다양한 업무를 맡아 왔습니다. 현재는 Exchange의 사용자 환경 관리자로 제품 디자인 및 고객 조사를 담당하고 있습니다. Exchange 팀에 합류하기 전에는 3년간 Outlook 테스터로 일하면서 사람들이 전자 메일에 첨부된 실행 파일을 차단하는 것이 어렵고 힘든 일이라고 생각하던 시기에 첨부 파일을 테스트하는 일을 맡았습니다. KC는 blogs.technet.com/kclemson(영문)에서 블로그를 운영하고 있습니다.

Paul은 지난 3년간 규모는 작지만 기능이 뛰어난 Exchange Best Practices Analyzer(ExBPA) 도구에 대한 업무를 담당해 오고 있습니다. 사실 그는 몇 달 전 ExBPA 도구로 상을 받았으며 Bill Gates와 사진도 촬영했습니다. 하지만 Exchange Server 2007 프로젝트가 마무리되어 가는 지금 이제는 역할을 바꿀 때가 왔습니다. Paul은 XML에 대한 환상에서 벗어나 현실로 돌아와야 합니다. 그는 Exchange Server 2007 출시 즉시 작업에 들어가게 될 버전인 다음 Exchange 버전의 릴리스 관리자로 활동할 예정입니다.

그나저나 이 재치 넘치는 칼럼 제목은 어떻게 보셨나요? 이 제목은 우리가 만든 것이 아니라 KC의 블로그를 방문한 한 독자가 제안한 것입니다. (셔츠 잘 입으세요, Tim!) 아쉽게 선정되지 못한 제목으로는 "새로운 한계에 도전하다(Pushing the Envelope)"와 "내가 만약 X64 버전이라면...(When I'm X64)"이 있었습니다. 특히 후자를 너무 마음에 들어 한 KC는 www.whenimx64.com이라는 도메인을 등록하고 자신의 블로그를 이 도메인에 연결했습니다. 우리가 살아가면서 이렇게 모든 것을 할 수 있는 능력을 가진다면 얼마나 좋을까요.

참고: KC는 처음에 이 칼럼의 이름을 "이번 달의 질문과 대답"으로 하자고 제안했지만 편집자는 아직 그 분량이 얼마나 될지, 우리가 일정에 맞추어 칼럼을 제공할 수 있을지 확신할 수가 없다는 점을 지적했습니다. 여기 우리보다 그의 대답은 훨씬 정중하고 퉁명스럽지 않았지만 우리는 그의 생각이 무엇인지 알고 있었습니다. 뿐만 아니라 이 칼럼을 읽은 독자들이 어떤 의견을 보내줄지, 이 칼럼을 계속 게재할 가치가 있는지도 확실히 알 수 없습니다. 따라서 우리는 그 중간쯤 되는 이름을 선택한 것입니다. 여러분의 의견을 queuea@microsoft.com으로 보내 주십시오.

이제 칼럼 제목에 대한 이야기는 여기서 접고 질문으로 넘어가겠습니다.

질문: Exchange Server 2007의 기대되는 특징으로는 무엇이 있습니까?

대답: 첫 번째 칼럼을 마케팅 냄새가 나는 질문으로 시작하는 것은 위험의 소지가 있다는 걸 알지만 Exchange Server 2007에 대한 기대가 너무 커서 정말로 여러분과 함께 나누고자 합니다. 이에 따라 마케팅적인 강연은 가급적 삼가고 Exchange 관리자 또는 사용자가 Exchange 2007을 기대해야 하는 수많은 기술적 이유를 몇 가지만 이야기하려고 합니다.

확장성 및 성능 향상

첫 번째 특징은 확실합니다. 바로 64비트라는 점입니다. 그게 뭐 그리 대단하냐고요? 그러니까 32비트 Windows®는 총 4GB(232바이트)의 메모리밖에 지원하지 못합니다. 그 중 2GB는 커널이 기본적으로 차지하고 나머지 2GB만 응용 프로그램이 사용할 수 있습니다. 현재 버전의 Windows는 boot.ini에서 /3GB 스위치를 지원하여 응용 프로그램에 최고 3GB의 메모리 공간을 제공하지만 이 스위치를 사용하면 Windows 커널에 작은 문제가 발생하게 되므로 서버를 재부팅하고 리소스를 회수하도록 결정하는 데 그리 오래 걸리지 않게 됩니다.

하지만 다행히도 Exchange에서는 64비트를 지원할 뿐만 아니라 기본 데이터베이스 엔진(JET)도 많이 변경되었으므로 이러한 문제가 해결되었습니다. Exchange Server는 지금까지 CPU와 같은 다른 시스템 리소스보다는 디스크 I/O 때문에 제한을 받는 경우가 훨씬 더 많았기 때문에 시스템에 메모리를 추가한다는 것은 디스크를 읽지 않고 메모리에 더 많은 정보를 보관함으로써 디스크 I/O를 상당히 줄일 수 있다는 것을 의미합니다. 결과적으로 Exchange 2007에서는 Exchange 2003과 유사한 물리적 하드웨어를 사용하더라도 Exchange 2003보다 훨씬 큰 사서함을 사용자에게 제공할 수 있습니다. 예를 들어, 현재 Microsoft에서 사용하고 있는 메일 서버는 2GB 사서함 용량으로 4,000명의 사용자를 지원하며 6TB(테라바이트)의 데이터를 보관합니다. 확실히 말해 두지만, Exchange 2007이 더 많은 메모리를 활용할 수 있다고 해서 그만큼 많은 메모리를 필요로 한다는 것은 아닙니다. 우리는 메모리가 4GB 이하인 32비트 Windows Server® 2003과 Exchange 2003을 실행하는 제품을 테스트해 본 후 64비트 Windows Server 2003과 Exchange 2007을 설치해 봤는데 성능이 비슷하게 나타났습니다.

Exchange 2007은 또한 CCR(Clustered Continuous Replication)과 LCR(Local Continuous Replication)이라는 두 가지 획기적인 방법으로 가용성을 높입니다. 이러한 기술은 심각한 문제를 야기하는 저장소 오류의 위험을 줄입니다. LCR은 데이터베이스의 로컬 복사본을 동일한 시스템에 보관하지만 이를 다른 저장소 미디어로 옮길 수도 있습니다. CCR은 네트워크를 통해 두 시스템 사이에서 동일한 작업을 수행할 수 있습니다. 이 CCR이 칼럼 초반부에 잠깐 설명했던 디스크 I/O 기능 개선과 맞물리면서 새로운 저장소 하드웨어 옵션을 제공하게 되었습니다. 다시 말해, SATA 또는 SCSI 드라이브와 같은 DAS(Direct Attached Storage) 미디어를 사용하고 싶은 경우 이제는 훨씬 경제적이고 성능이 좋은 옵션을 선택할 수 있습니다.

관리

Microsoft는 Exchange 2007에서 그림 1과 같은 명령줄 인터페이스가 포함된 새로운 관리 환경을 개발하기 위해 엄청난 투자를 했습니다. EMS(Exchange 관리 셸)라고 불리는 이 기술은 Windows PowerShell™에 기반을 두고 있습니다. GUI가 계속해서 제공되므로 명령줄을 선호하지 않아도 상관없습니다. 다만 이제는 GUI가 EMC(Exchange 관리 콘솔)라는 이름으로 제공되며 이는 과거의 시스템 관리자에 비해 훨씬 직관적인 인터페이스입니다(그림 2 참조). 명령줄 인터페이스를 사용해 왔거나 앞으로 그럴 계획이라면 Exchange 2007의 EMS를 확인해 보십시오.

그림 1** EMS(Exchange 관리 셸)의 저장소 그룹 상태 **(더 크게 보려면 이미지를 클릭하십시오.)

그림 2** EMC(Exchange 관리 콘솔)의 동일한 상태 **(더 크게 보려면 이미지를 클릭하십시오.)

Exchange 2003에서는 WMI(Windows Management Instrumentation) 스크립트를 사용하여 보다 복잡한 관리 작업을 수행해야 했을 것입니다. 하지만 EMS를 사용하면 "CD C:\TEMP"의 내용을 어느 정도 이해할 수 있는 사용자라면 누구나 이러한 관리 작업을 수행할 수 있습니다. 우리 중 하나는 이전에 UNIX sysadmin 역할을 했고 그래서 객관성이 문제가 될지 모르지만, 과거에 명령줄을 한 번도 사용해 보지 않은 사람에게도 이 셸은 믿을 수 없을 만큼 직관적이라고 보증해 줄 객관적인 다른 사람들을 얼마든지 알려드릴 수 있습니다. 자세한 내용은 다음 Exchange Queue & A 칼럼에서 논의하겠습니다.

Windows PowerShell의 강점은 개체 지향이라는 것입니다. 서버에서 사서함이나 SMTP 커넥터 목록 등의 정보를 검색하면 이 정보는 자동으로 개체나 변수에 저장되고 쉽게 읽을 수 있도록 텍스트로 stdout에 스트리밍됩니다. 그러면 이 개체는 다른 명령으로 직접 전달되어 파이프라인에서 작동됩니다. 이 경우 텍스트가 아닌 개체를 따라 전달되므로 데이터를 수정하거나 데이터 일부를 작업하기가 쉽습니다. 간단한 예를 들어 보겠습니다.

Get-Mailbox | Set-Mailbox -ProhibitSendQuota 250MB

Get-Mailbox 명령은 시스템에서 사서함 목록을 검색합니다. 파이프 기호라고 하는 |는 왼쪽에 있는 명령의 출력이 오른쪽에 있는 명령으로 전달되어야 한다는 것을 나타냅니다. 그 다음 부분인 "Set-Mailbox-ProhibitSendQuota 250MB"는 사서함 전체의 크기가 250MB에 도달하면 더 이상 전자 메일을 보낼 수 없다는 것을 의미합니다. 셸은 데이터를 처리하는 방식이 매우 유연하므로 할당량을 250000000, 250000KB 또는 0.25GB로 설정할 수도 있습니다.

Exchange 2007에서 향상된 또 다른 유용한 관리 기능은 Outlook에 있는 것과 매우 유사한 규칙 마법사를 사용하여 비즈니스 논리를 시스템을 통해 전달되는 메시지에 적용하는 전송 규칙을 생성할 수 있는 기능입니다. 정규식을 바탕으로 본문에 주민 등록 번호가 포함되어 있는 것으로 보이는 전자 메일을 차단하고 싶으세요? 선택만 하세요. 조직 내 두 부서가 서로 전자 메일을 주고 받지 못하도록 교신 차단 영역을 설정하고 싶으세요? 선택만 하세요. 조직 외부로 나가는 모든 전자 메일에 법적 고지 사항을 추가하고 싶으세요? 선택만 하세요.

우리가 큰 기대를 갖고 있는 마지막 관리 기능은 사용자 지정이 가능한 시스템 메시지입니다. 이제는 기본적으로 사용자 지정 텍스트를 배달 못 함 보고서에 추가할 수 있을 뿐만 아니라 드디어 저장소 할당량을 초과할 때 사용자에게 표시되는 메시지도 추가할 수 있게 되었습니다.

기술 지원 부서 지원

많은 고객들이 가장 많이 지출하는 비용 중 하나가 Outlook에서 새 프로필을 구성하는 것과 관련된 기술 지원 부서 비용입니다. Outlook 2007에는 자동 검색이라는 기능이 있어서 Outlook을 시작하기만 하면 서비스 연결 지점을 통해 자동으로 전자 메일 주소가 조회되고 Active Directory®에서 Exchange Server 정보가 검색됩니다. Active Directory에 연결되어 있지 않더라도 전자 메일 주소와 암호만 입력하면 자동 검색 조회를 통해 http://autodiscover.contoso.com과 같은 지정된 웹 서버에서 RPC over HTTP(현재는 '외부에서 Outlook 사용'이라고 함)에 사용할 서버 등의 기본적인 구성 정보가 들어 있는 XML 파일을 다운로드할 수 있습니다.

또한 스팸 필터에서 메시지가 잘못 걸러지는 피할 수 없는 문제를 관리하는 데에도 많은 기술 지원 부서 비용이 지출됩니다. 사용자는 콘텐츠 필터링에서 걸러지지 않아야 하는 메시지를 보낸 사람들의 목록을 Outlook에 안전하게 보관할 수 있지만 Exchange 2007 이전 버전에서는 이러한 목록에서 메시지가 Outlook 필터만 그냥 통과하도록 합니다. 하지만 Outlook이 메시지를 보기 전에 Exchange 필터가 그러한 메시지를 처리하므로 사용자는 여전히 신뢰할 수 있는 사람들이 보낸 전자 메일을 놓칠 가능성이 있었습니다.

Exchange 2007은 여기서도 도움이 됩니다. 사용자가 Exchange 2007에서 Edge 또는 Hub 서버 역할을 통해 스팸 콘텐츠를 걸러내는 필터를 사용할 경우 사용자의 수신 허용 목록을 해당 서버에 전파하여 그러한 보낸 사람이 보낸 메시지가 스팸 콘텐츠 필터에서 걸러지지 않도록 구성할 수 있습니다. 물론 어떤 사용자에게는 스팸인 전자 메일이 다른 사용자에게는 회보가 될 수도 있기 때문에 수신 허용 목록은 사용자 각각을 기준으로 작성됩니다.

최종 사용자 혜택

Exchange 2007의 UM(통합 메시징) 기능을 사용하여 받은 편지함을 통해 인바운드 음성 메일과 팩스를 받을 수 있습니다. 과거에 이 기능을 사용해 본 적이 없다면 무엇을 놓치고 있는지도 모를 것입니다. 또한 Exchange Server를 호출하여 오전 8시 모임의 모든 참석자에게 자신이 늦을 거라는 사실을 알려주도록 설정할 수도 있습니다. 아무리 작은 조직도 쉽게 자동 전화 교환을 사용자 지정하고 브랜딩하여 고객이 전화를 걸었을 때 시스템이 자동으로 적절한 곳으로 전화를 연결하도록 할 수 있습니다. UM 기능을 사용하려면 IP 기반 PBX(IP/PBX)를 사용하거나 전통적인 회로-스위치 기반 PBX를 VoIP(Voice over IP) 게이트웨이에 연결해야 합니다.

링크 액세스는 OWA 2007의 새로운 기능입니다. 이동 중인 경우 VPN 클라이언트가 설치되어 있지 않은데 파일 공유에 있는 Microsoft Word 문서를 봐야 하거나 회사 네트워크에 있는 SharePoint® 사이트를 확인해야 할 경우에는 어떻게 해야 할까요? 아무 문제 없습니다. OWA 2007을 로드해서 문서 링크로 이동한 다음 공유 또는 SharePoint 사이트(http://mysharepointsite 및 \\server\share) 이름을 입력하고 파일을 찾아서 열면 됩니다. 물론 관리자는 풍부한 보안 기능을 통해 파일에 액세스하지 못하도록 잠글 수 있습니다. 이뿐만 아니라 특정 목록을 제외한 모든 서버를 허용하거나, 특정 목록을 제외한 모든 서버를 거부하거나, 사용자가 개인 컴퓨터에서 OWA에 로그인할 때 문서 액세스만 허용하는 등 원하는 대로 액세스를 통제할 수 있습니다.

OWA에는 WebReady 문서 보기(전문가들은 이를 "트랜스코딩"이라고 부름)이라는 기능이 있어서 로컬에 올바른 응용 프로그램이 설치되어 있지 않을 경우 특정 형식의 파일을 HTML로 렌더링하도록 Exchange에 명령할 수 있습니다. Exchange 2007은 DOC, DOT, RTF, WBK, WIZ, XLS, XLK, PPT, PPS, POT, PWS, PDF 등과 같은 파일 형식의 트랜스코딩을 기본적으로 지원할 예정입니다. 트랜스코딩 엔진에는 새로운 파일 형식에 대한 지원을 서비스 팩에 추가할 수 있도록 플러그형 아키텍처를 채택했습니다. 또한 사용자에게 트랜스코딩을 허용할 파일 형식이나 완전히 트랜스코딩을 금지할 파일 형식을 결정할 수 있도록 관리 옵션도 포함되어 있습니다.

Exchange ActiveSync®를 사용하여 Exchange와 동기화되는 모바일 장치가 있는 경우 전자 메일 스레드에 회신하거나 이를 전달하면 메시지가 더 이상 일반 텍스트로 변환되지 않습니다. 텍스트는 맨 위에 추가되지만 메시지 나머지의 HTML 본문은 그대로 남아 있습니다. 이는 ActiveSync를 지원하는 모든 장치에서 마찬가지입니다. 이 경우 클라이언트의 기능은 필요하지 않습니다.

질문: Exchange 2007이 "프로덕션 목적일 때만 64비트"라는 말을 들었는데 이게 무슨 뜻입니까?

대답: Exchange 2007은 32비트나 64비트로 모두 사용할 수 있습니다. 64비트 버전은 핵심 서버 역할(사서함, Hub 전송, Edge 전송, 클라이언트 액세스, 통합 메시징)의 프로덕션 "라이브" 사용을 목적으로 설계되었습니다. 32비트 버전은 Exchange 2007의 새로운 기능을 평가할 목적으로 설계되었습니다. 또한 관리 도구를 프로덕션 환경에서 32비트로 사용할 수도 있기 때문에 32비트 Windows XP 데스크톱 시스템에서 64비트 Exchange 2007 프로덕션 서버를 관리할 수 있습니다. 또한 Exchange 2007 스키마는 루트 도메인의 시스템에서 설치해야 합니다. Exchange 자체는 루트 도메인에 설치할 필요가 없지만 스키마 마스터와의 양호한 네트워크 연결을 위해 스키마 확장은 루트 디렉터리에서 이루어져야 합니다. 도메인에 64비트 서버가 없다면 32비트 버전의 setup.exe를 사용하여 스키마를 확장할 수 있습니다.

32비트 서버는 뭐가 문제냐고요? 한 대의 서버로 수천 명의 사용자를 지원해 왔다면 앞서 설명한 메모리 제한으로 인해 성능과 안정성 사이에 균형을 맞추는 작업이 상당한 작업이라는 사실을 알 것입니다. 지난 2년 사이에 새 컴퓨터를 구입했다면 이미 x64 확장을 지원하고 있을 수 있습니다. 사실 요즘에는 64비트 모드를 지원하지 않는 새 컴퓨터를 산다는 것이 상당히 어렵습니다. 따라서 현재 환경에서 이미 Exchange를 실행하고 있는 시스템은 64비트를 지원할 가능성이 있습니다. 다만 32비트 운영 체제를 실행하고 있을 뿐입니다. 그렇다면 어떻게 해야 할까요? 64비트를 지원하는 새 컴퓨터를 구입한 후에 64비트 버전의 Windows Server 2003 SP1을 설치해야 합니다.

그렇다면 프로덕션 환경에서 설치할 때 32비트 설치를 사용하지 않는다면서 경고가 나타나는 이유는 무엇일까요? Exchange는 여러 가지 방식으로 컴파일하기가 상당히 쉽지만 각 구성 요소는 64비트에 대해서만 100% 최적화되고 조정됩니다. 64비트 시스템에서 디스크 I/O 기능을 개선하기 위해 선택했던 코드 경로 일부가 실제로는 32비트 환경에서 성능 저하를 가져오기도 합니다. 32비트로 사전 점검을 하려고 한다면 시뮬레이션이든 뭐든 Exchange가 별 무리 없이 실행될 것이라고 생각하지 마십시오. 현실적으로는 64비트 시스템에서 Exchange가 어떻게 작동할지 또는 얼마나 많은 사용자를 서버에서 처리할 수 있을지 알지 못할 것입니다.

모두 이해되셨나요? 32비트 버전의 Exchange 2007로는 다음과 같은 작업을 할 수 있습니다.

• 사용 중인 사용자 사서함이 없는 테스트 서버에서 새 기능을 평가할 수 있습니다.
• 새로운 관리 콘솔, 셸 또는 OWA 인터페이스를 살펴볼 수 있습니다. 그렇다고 이러한 기능에 너무 놀라지는 마십시오.
• Exchange 2007 서버를 관리할 수 있습니다.
• Active Directory 포리스트의 스키마를 확장할 수 있습니다.

사서함을 옮길 준비가 되면 서버에서 64비트 Exchange 2007이 설치된 64비트 운영 체제를 실행해야 합니다. 그렇지 않을 경우 설치 프로그램 및 ExBPA 때문에 번거로운 일이 많이 생길 것입니다(그림 3 참조). Paul은 이것이 빈말이 아니라는 것을 잘 압니다. 그가 바로 코드를 작성했으니까요!

그림 3** 64비트만 지원되는 시스템에 32비트를 설치하려는 경우 **(더 크게 보려면 이미지를 클릭하십시오.)

질문: Exchange 2007을 실행하려면 메모리가 얼마나 필요합니까?

대답: 기본 설치에는 최소 1GB의 RAM이 필요합니다. 앞서 언급했듯이 서버 역할 중 일부는 메모리를 많이 필요로 합니다. 사서함, 클라이언트 액세스, Hub 전송 및 통합 메시징과 같은 통합 서버를 설치하려고 한다면 2GB의 RAM으로 시작해서 사서함의 수와 사용량에 따라 확장하는 것이 좋을 것입니다. Edge 역할 또는 클러스터를 설치하려고 한다면 이는 별도의 시스템에 설치해야 합니다. 클러스터에는 사서함 역할만 설치할 수 있습니다. 다른 역할은 설치할 수 없습니다.

드디어 Exchange Server에 4GB 이상의 RAM을 설치할 수 있다는 사실을 알면 기뻐하는 사람들이 많을 것입니다. 현재 시스템의 대다수는 6GB 또는 8GB가 표준이기 때문에 항상 울며 겨자 먹기 식으로 DDR(Double Data Rate) 모듈을 빼내거나 /BurnMemory를 사용하여 RAM을 4GB로 줄여야 했습니다. 더군다나 Exchange 2003의 경우 RAM이 4GB를 초과하면 성능과 안정성이 떨어집니다. 자세한 내용은 go.microsoft.com/fwlink/?LinkId=76537(영문)을 참조하십시오.

Hub, 클라이언트 액세스 등의 인프라 서버의 경우 RAM이 4GB 미만이어도, 심지어 부하가 최고조에 다다른 경우에도 괜찮습니다. 비용을 들여야 할 곳은 사서함 서버입니다. 새롭게 최적화된 이 64비트 JET 캐시는 메모리를 던져주는 대로 다 사용하려고 할 것입니다. 물론 Exchange 2003과 달리 Exchange 2007에서는 최고 50개의 저장소 그룹을 지원합니다.

각 저장소 그룹은 여러 개의 데이터베이스를 지원할 수 있지만 이러한 사실은 아무 도움도 되지 않습니다. 특히 LCR과 CCR(앞서 설명했던 두 가지 유형의 데이터베이스 복제)은 단일 데이터베이스가 있는 저장소 그룹에서만 작동할 수 있기 때문에 더욱 그렇습니다. 많은 수의 저장소 그룹을 만들 생각이거나 각 사용자마다 2GB 이상의 사서함을 제공할 꿈을 꾸고 있다면 반드시 이에 대한 RAM을 추가해야 할 것입니다. RAM 크기 지정에 대한 내용은 Exchange 팀 블로그(영문)에 자세히 나와 있지만 그림 4 및 5에서 참고 자료를 미리 확인하십시오.

Figure 5 RAM 및 저장소 그룹

Figure 4 사용자 유형별 RAM

한편, Microsoft IT는 반복되는 백업 일정을 가지고 있지만 특정 날에는 그 중 일부 저장소 그룹만 백업하기 때문에 7의 배수로 된 많은 저장소 그룹을 사용합니다. 백업 일정이 나와 있는 Excel 스프레드시트에는 특정 날에 백업되는 저장소 그룹이 계단식으로 빨간색으로 표시되기 때문에 우리는 이 일정을 "지팡이 사탕 백업"이라고 부릅니다. 이번 칼럼이 도움이 되었기를 바랍니다. 다음 호에 실을 "진짜" 질문을 보내 주시기 바랍니다.

KC Lemson은 Exchange Server 팀의 선임 프로그램 관리자로서, 여유 시간에는 나이지리아 왕족의 자금 보호를 돕고 있습니다.

Paul Bowden도 Exchange Server 팀의선임 프로그램관리자로서, 주문이 있을 때마다 자신의 PayPal 계정 정보를 재확인하는 데 여유 시간의 대부분을 보냅니다.

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