 TechNet Magazine December 2006
TechNet Magazine December 2006
DECEMBER 2006
Exchange Server 2007

Exchange 2007로 전환하기 위한 준비를 하고 계시다면 제대로 찾아 오셨습니다. 이번 호에서는 업그레이드를 준비하는 방법, Exchange 관리 셸을 사용하여 Exchange 관리 스크립트를 작성하는 방법, Outlook Web Access와 Exchange 2007을 결합하여 어디에서나 이용할 수 있는 최상의 통합 메시징 시스템을 구축하는 방법 등을 소개하려고 합니다.

또한 Exchange Server 2007과 Outlook 2007 클라이언트의 업그레이드된 최신 기능과, Sender ID Framework를 사용하여 효과적으로 스팸에 대처하는 방법, 제어와 규정 준수를 위해 Exchange 2007에서 저널링을 탐색하는 방법을 다룹니다.
주요 기사
Exchange Server 2007 Exchange 2007로 인프라 업그레이드

조직이 크든 작든 Exchange Server 2007로 원활하게 전환하려면 미리 계획을 세워야 합니다. 올바른 계획이 마련되어 있다면 서비스 중단을 피할 수 있습니다. 다음은 업그레이드를 수행할 때 따라야 할 단계입니다.

Kate Follis Exchange 관리 셸을 통한 명령 수행

Exchange 관리 셸은 관리자에게 Exchange Server 2007의 모든 기능을 관리할 수 있는 강력한 인터페이스를 제공합니다. 이 칼럼에서는 명령줄에서 스크립트 작성, 응용 프로그램 통합 및 기타 강력한 관리 작업을 수행하는 방법을 개략적으로 설명합니다.

David Strome Exchange & Outlook: 더 나아진 통합

Exchange Server 2007과 Microsoft Office Outlook 2007은 통신 및 공동 작업에 있어 큰 도약을 이루어냈습니다. 보다 간편해진 구성, 향상된 검색 기능, 통합 메시징 등이 어떻게 이루어졌는지 확인해 보십시오.

Michael Khalili Exchange 2007을 사용한 중단 없는 연결

현재 통신은 과거 그 어느 때보다도 훨씬 강력해졌습니다. Exchange Server 2007에서 기본적으로 제공하는 통합 메시징과 Outlook Web Access 기능을 사용하여 어떻게 사용자의 모든 메시지를 한 곳에 통합하여 어디서나 액세스할 수 있는지 살펴보겠습니다.

Joshua Trupin Exchange 2007의 더욱 강력해진 저널링

Exchange Server 2007에서 훨씬 더 유연해진 저널링 기능을 사용하여 보다 쉽게 대규모 조직 내에서 특정 사용자 계정을 모니터링하고 규정 준수 요구 사항을 충족할 수 있습니다.

David Strome 보낸 사람 ID로 스팸 및 피싱 방지

SDIF(Sender ID Framework)에 기반한 전자 메일 인증이 널리 채택되어 스팸 및 피싱 메시지 방지에 크게 기여하고 있으며 실제로 전 세계의 전자 메일 볼륨 중 1/3 이상이 이미 인증되어 SIDF를 준수합니다. 다음은 SDIF 작동 방식입니다.

Craig Spiezle과 Alexander Nikolayev
칼럼
From the Editor

더 넓은 도약

Joshua Trupin Toolbox

IT 전문가를 위한 새로운 제품

Greg Steen Windows PowerShell

간단한 명령, 강력한 관리

Don Jones Post Mortem

Exchange 5.5에서 마이그레이션

Whitney Roberts 		SQL Q+A

재부팅 방지, 여러 업데이트 설치 및 기타 질문

편집자: Nancy Michell Hey, Scripting Guy!

컵 홀더는 어디 있을까요?

The Microsoft Scripting Guys Security Watch

전역 트러스트된 PKI 배포

John Morello The Desktop Files

Windows 이미징 형식 내부

Wes Miller Windows Confidential

RunOnce 대기

Raymond Chen


 Exchange Server 2007: Exchange 2007로 인프라 업그레이드
Exchange Server 2007 Kate Follis

Exchange 2007로 인프라 업그레이드
한 눈에 보기:
  • Exchange 2007의 새로운 기능
  • 업그레이드 준비
  • 역할 기반 배포
  • 메시지 라우팅 토폴로지

Exchange Server 5.5에서 Exchange 2000 Server로의 마이그레이션에 대해 강의한 적이 있는데, 오전 8:30에 시작해서 오후 6:00 무렵에 수업이 끝나게 되어 집에 돌아갈 때는
거의 탈진한 상태가 되곤 했습니다. 디렉터리 리소스 이동, NTDSNoMatch에 대한 많은 혼란, 트러스트되기를 거부하는 우발적인 Windows NT® 4.0 트러스트 등과 관련된 많은 준비 작업이 있었습니다. 시간의 제약으로 Exchange 2000 Server 관리에 대해서는 거의 다루지 못했지만 금요일 밤에 강의실에서 나와 주말 동안 마이그레이션을 끝내려고 했던 소수의 열성적인 수강생들이 변함 없이 있었습니다. 그럴 때마다 주의를 주면서 계획에 더 많은 시간을 투자하라고 권하곤 했지만 그들이 따랐는지는 의문입니다.
Exchange 2000 Server나 Exchange Server 2003에서 Exchange Server 2007로 전환하려는 경우에도 이와 같은 주의가 필요합니다. 즉, 계획에 충분한 시간을 투자해야 합니다. 실제 전환 프로세스는 조직과 현재 배포의 복잡도에 따라 다르지만 여전히 여러 가지 단계가 필요합니다. 규모가 작은 조직에서는 이러한 단계를 단일 프로젝트로 수행할 수 있지만 규모가 큰 조직에서는 점진적으로 서버 역할을 도입하고 일정 기간 동안 함께 사용하는 방식으로 Exchange를 지원하도록 결정할 수 있습니다. 종단 간 프로세스는 전체 전환 기간 동안 메시징 기능과 안정성을 유지하도록 설계되었습니다. 이 기사에서는 Exchange Server 2007로 업그레이드할 때 조직에서 메시지 흐름을 유지 관리하는 데 필요한 필수 단계를 중심으로 설명합니다.

고려 사항
고려해야 할 첫 번째 요구 사항은 64비트 하드웨어에 Exchange Server 2007을 배포해야 한다는 것과 이전 버전의 Exchange에서 곧바로 업그레이드할 수는 없다는 것입니다. 스윙 업그레이드(Swing Upgrade) 방법을 사용하여 기존 메시징 서비스를 Exchange 2007로 마이그레이션해야 합니다. 또한 Exchange 조직이 기본 모드로 운영되고 있어야 Exchange 2007 서버를 추가할 수 있으므로, 조직에서 현재 Exchange 5.5를 사용하고 있으면 Exchange Server 2003으로의 중간 업그레이드를 수행한 후에 Exchange 2007로 이동해야 합니다.
Exchange 2007에는 전환 계획 시 고려해야 할 중요한 변경 내용이 몇 가지 있습니다. 예를 들어 Exchange 2007에 도입된 역할 기반 배포를 사용하면 제공하려는 메시징 서비스를 선택하고 이러한 서비스에 관련된 서버 역할을 배포할 수 있습니다. 전용 하드웨어에 개별적으로 서버 역할을 배포하거나 동일한 실제 서버에 개별 엔터티로 관리되는 여러 개의 역할을 설치할 수 있습니다. 각각에 대한 설명은 "Exchange 2007 서버 역할"을 참조하십시오.
Exchange Server 2007 서버 역할
사서함 서버 사서함 서버 역할은 조직에 메시지 저장소를 제공합니다. Exchange 2007에서는 서버당 최대 50개의 저장소를 지원할 수 있습니다. 이러한 저장소를 50개의 개별 저장소 그룹으로 배포할 수도 있고 단일 저장소 그룹에 최대 50개의 저장소를 만들 수도 있습니다. 클러스터로 배포할 수 있는 역할은 사서함 서버 역할뿐이므로 클러스터링을 사용하려는 경우에는 전용 하드웨어에 사서함 서버를 설치해야 합니다.
클라이언트 액세스 서버 클라이언트 액세스 서버 역할은 프런트 엔드 서버가 제공하는 기능을 대체합니다. 이 역할은 POP3, IMAP4, OWA(Outlook® Web Access), RPC over HTTPS(이제 Outlook Anywhere라고 함), Exchange ActiveSync® 등을 사용하여 Exchange에 액세스하는 클라이언트에 사서함 액세스를 제공합니다.
Hub 전송 서버 이 역할은 Exchange 조직에 SMTP 및 MAPI 메시지 전송 서비스를 제공합니다. 조직 내 사용자가 보내거나 받는 모든 메시지는 Hub 전송 서버가 처리합니다. 이 역할은 조직 내 모든 메시지가 전송 파이프라인의 여러 지점에서 실행되는 에이전트의 서버 기반 규칙이나 저널링 정책을 우회하지 못하도록 하므로 매우 유용합니다.
통합 메시징 서버 이 역할은 사서함에 대한 음성 액세스를 제공합니다. IP/VoIP 게이트웨이나 IP-PBX와 통합되어 메시지와 일정 항목에 대한 전화 액세스를 제공하며 회신을 적을 수 있게 해 줍니다. 이 역할은 Exchange에 새로 추가된 것이므로 이전 버전의 Exchange와 상호 운용할 수 없습니다.
Edge 전송 서버 Edge 전송 서버는 일반적으로 경계 네트워크에 배포되어 Exchange 조직과 인터넷 간의 SMTP 메시지 전송을 제공하고 전송 에이전트를 사용하여 스팸 방지 및 바이러스 백신 처리 기능을 제공합니다. 이제 조직 네트워크 서버와 경계 네트워크 서버 모두에 대해 단일 기술을 표준으로 지정할 수 있습니다. 이 원활한 상호 작용 모델을 통해 관리를 단순화하고 경계 서버를 간편하게 통합할 수 있습니다.

토폴로지 검사
그러면 무엇부터 시작할까요? 현재 상황을 알지 못한다면 어느 방향으로 이동해야 하는지 알기 어렵습니다. 충분한 시간을 두고 현재 환경을 평가하고 토폴로지를 문서화하십시오. 여기에는 Exchange뿐만 아니라 Active Directory® 환경도 포함됩니다. Exchange 2007에서는 링크 상태 라우팅과 라우팅 그룹 및 커넥터에 기반한 토폴로지를 제거하며 조직에서 Active Directory 토폴로지를 설계할 때 투자한 기존 인프라를 활용합니다. 따라서 Active Directory에 모든 Exchange 받는 사람 및 구성 데이터가 저장되고 Active Directory 사이트 구성에서 라우팅 토폴로지가 파생되며 모든 서버 역할이 사이트 인식을 사용하여 다른 서버 역할에서 실행되고 있는 서비스를 검색합니다.
현재 Active Directory 사이트 토폴로지가 기본 실제 네트워크를 정말로 이용하는지, 그리고 모든 Active Directory 사이트가 연결된 서브넷을 가지고 있는지 확인한 다음 기존 Active Directory 사이트와 IP 사이트 링크를 문서화합니다. 모든 Exchange 2003 서버의 실제 위치와 라우팅 그룹 및 라우팅 그룹 커넥터 구조도 문서화합니다.
전환 프로세스에서 가장 까다로운 부분은 라우팅 그룹 기반의 Exchange 라우팅 인프라에서 Active Directory 사이트 기반의 라우팅 인프라로 이동하는 것입니다. 규모가 작은 조직의 경우에는 일반적으로 이 프로세스가 단순하지만 라우팅 그룹이 많은 대규모 조직의 경우에는 Exchange 2003과 Exchange 2007이 공존할 때 중간 단계를 면밀하게 계획해야 합니다. Exchange 2007 사용자가 Exchange 2003 사서함에 보낸 메시지가 낮은 대역폭 연결을 통해 여러 원격 라우팅 그룹을 거치는 것을 원하지는 않을 것이기 때문입니다.
현재 토폴로지에 대해 몇 가지 사항을 가정하는 것으로 시작해 보겠습니다.
  • Exchange 2003 조직이 기본 모드로 실행되고 있습니다.
  • 둘 이상의 라우팅 그룹이 있습니다.
  • 둘 이상의 Active Directory 사이트가 있습니다.
그림 1에서는 Exchange 및 Active Directory 토폴로지를 보여 줍니다. 준비 계획에 포함하는 정보가 자세할수록 더욱 효과적으로 설계할 수 있습니다.
그림 1 Exchange 및 Active Directory 토폴로지
그림 1 Exchange 및 Active Directory 토폴로지 (더 작게 보려면 이미지를 클릭하십시오.)
그림 1 Exchange 및 Active Directory 토폴로지
그림 1 Exchange 및 Active Directory 토폴로지 (더 크게 보려면 이미지를 클릭하십시오.)

Exchange 2007에서 Active Directory를 사용하는 방법
Exchange 2007 서버가 시작되면 해당 서비스에 사이트 속성이 찍힙니다. 이를 통해 이 서버가 제공하는 서비스를 다른 Exchange 2007 서버가 찾을 수 있습니다. Hub 전송 서버만 SMTP를 사용하여 조직 내에서 메시지를 전송할 수 있습니다. 사서함 서버가 포함된 각각의 Active Directory 사이트에는 Hub 전송 서버도 포함되어야 합니다. 또한 사서함 사용자가 MAPI가 아닌 다른 방법을 사용하여 사서함에 액세스하는 경우에는 각 사이트에 클라이언트 액세스 서버도 포함되어야 합니다. 배달을 위해 메시지를 Hub 전송 서버로 전달하면 Hub 전송 서버는 이 메시지를 라우팅할 방법을 결정합니다. Hub 전송 서버와 동일한 Active Directory 사이트에 있는 사서함 서버로 라우팅 방향이 정해지면 Hub 전송 서버는 메시지를 사서함에 배달합니다. 다른 사이트에 있는 사서함 서버로 메시지의 라우팅 방향이 지정되는 경우 Hub 전송 서버는 이 메시지를 원격 사이트에 있는 Hub 전송 서버로 직접 릴레이합니다.
Hub 전송 서버는 Active Directory IP 사이트 링크 비용 정보를 사용하여 받는 사람 사서함이 위치한 Active Directory 사이트에 도달하는 경로 중에서 비용이 가장 낮은 경로를 계산합니다. 경로 선택 알고리즘은 Exchange 2003과 매우 비슷하지만 라우팅 그룹 커넥터 비용 대신에 IP 사이트 링크 비용을 기반으로 합니다. 또한 메시지가 전송 중 각 Hub 전송 서버에 머무르지 않고 원본에서 대상으로 직접 이동합니다. 그렇다면 IP 네트워크를 사용하여 메시지를 전송하면서 굳이 비용이 가장 낮은 경로를 계산하는 이유는 무엇일까요? 여기에는 몇 가지 이유가 있습니다. 하나는 메시지 분기 지연입니다. 두 명 이상의 받는 사람에게 보내는 메시지는 둘 이상의 Active Directory 사이트에 있는 사서함 서버에 배달해야 할 수 있습니다. Exchange 2007에서는 메시지가 첫 번째 Hub 전송 서버에서 분기되거나 분할되는 대신에 라우팅 경로에 있는 포크에 도달해야 분할됩니다. 따라서 메시지가 Active Directory 사이트에서 분기 지점을 나타내는 Hub 전송 서버로 직접 릴레이됩니다. 이러한 동작을 지연된 팬아웃(Delayed Fan-Out)이라고 합니다.
비용이 가장 낮은 경로는 대상에 도달할 수 없는 경우 메시지가 대기할 위치를 결정하는 데도 사용됩니다. 대상 Active Directory 사이트에 있는 Hub 전송 서버에 도달할 수 없는 경우 보내는 Hub 전송 서버는 라우팅 경로에 따라 가장 가까운 다음 Active Directory 사이트에 있는 Hub 전송 서버로 배달하려고 시도합니다. 메시지 배달은 Hub 전송 서버를 사용할 수 있는 Active Directory 사이트에 도달할 때까지 비용이 가장 낮은 경로를 따라 계속됩니다. 최종적으로 받는 사람의 Active Directory 사이트에 이르는 경로를 따라 사용할 수 있는 Hub 전송 서버가 없으면 메시지가 로컬에서 대기합니다. 이 방법을 사용하면 배달 지점에 최대한 가까운 곳에서 메시지가 대기하므로 네트워크 오류 진단이 보다 명확해집니다. 이러한 동작을 장애 지점에서 대기(Queue-at-Point-of-Failure)라고 합니다.
Exchange 2003은 전혀 다른 방식으로 작동합니다. 라우팅 그룹 커넥터에 할당된 비용을 기반으로 하나의 라우팅 그룹에서 다른 라우팅 그룹에 이르는 경로 중 비용이 가장 낮은 경로가 계산됩니다. 라우팅 경로를 따라 각 라우팅 그룹에 있는 브리지헤드 서버가 메시지를 받아서 릴레이합니다. 경로에 있는 다음 커넥터를 사용할 수 없는 경우 대체 경로가 계산됩니다. 다른 Exchange 서버에 연결이 끊겼음을 알려 주는 링크 상태 업데이트 메시지가 Exchange 조직 전반에 걸쳐 전달됩니다. 브리지헤드 서버는 연결이 설정되었음을 나타내는 링크 상태 알림을 받을 때까지 연결이 끊긴 커넥터를 우회하는 라우팅을 시도합니다.
대규모 조직을 전환할 때의 문제는 공존 기간 중에 메일 흐름을 유지 관리하는 것입니다. Exchange 2007이 프로덕션 환경에 도입될 때 이러한 연속성을 달성하기 위해 모든 Exchange 2007 서버는 단일 라우팅 그룹의 구성원이 됩니다. 즉, Exchange 2007 서버가 어느 Active Directory 사이트에 있는지에 관계없이 Exchange 2003은 Exchange 2007 서버가 단일 라우팅 그룹에 속한다고 간주합니다. 따라서 해당 라우팅 그룹과 Exchange 2003 라우팅 그룹 간에 라우팅 그룹 커넥터를 설정할 수 있으므로 Exchange 2003은 메시지를 Exchange 2007로 라우팅하는 방법을 파악할 수 있습니다. 또한 Exchange 2007은 라우팅 그룹 커넥터를 사용하여 메시지를 Exchange 2003에 보내는 방법을 결정합니다. 그러나 Exchange 2007은 항상 다른 Exchange 2007 서버를 통해 메시지를 라우팅하는 것을 선호하며 Exchange 2003 라우팅 그룹의 백본을 통해서는 결코 다른 Exchange 2007 서버에 도달하지 않습니다.

첫 번째 Exchange 2007 서버 도입
Exchange 2003 조직에 첫 번째 Exchange 2007 서버를 설치할 때는 첫 번째 라우팅 그룹 커넥터를 설정할 Exchange 2003 브리지헤드 서버를 선택해야 합니다.
그림 2에서는 첫 번째 Exchange 2007 서버 도입이 조직 토폴로지에 미치는 영향을 보여 줍니다.
그림 2 첫 번째 Exchange 2007 서버 설치
그림 2 첫 번째 Exchange 2007 서버 설치 (더 작게 보려면 이미지를 클릭하십시오.)
그림 2 첫 번째 Exchange 2007 서버 설치
그림 2 첫 번째 Exchange 2007 서버 설치 (더 크게 보려면 이미지를 클릭하십시오.)
지금까지는 아주 좋습니다. Exchange 2007이 만든 라우팅 그룹 커넥터의 기본 비용은 1입니다. 메일은 계속해서 Exchange 2003 서버를 통해 평소대로 흐릅니다. Exchange 2003 서버에서 Exchange 2007 서버 사용자에게 메시지를 보내면 아카풀코 라우팅 그룹을 통과합니다. 라우팅 그룹 커넥터가 생성되면 선택한 Exchange 2003 브리지헤드 서버는 자동으로 ExchangeLegacyInterop 유니버설 보안 그룹의 구성원이 되고 Exchange 2007에 전자 메일 메시지를 보내거나 Exchange 2007에서 전자 메일 메시지를 받을 수 있는 올바른 사용 권한을 부여받습니다. Exchange 2007 서버가 커넥터의 원본이나 대상 서버로 지정될 때마다 항상 Exchange 관리 셸에서 New-RoutingGroupConnector를 사용하여 라우팅 그룹 커넥터를 만들어야 합니다. Set-RoutingGroupConnector cmdlet을 사용하여 라우팅 그룹 커넥터의 구성을 수정할 수도 있습니다. 예를 들어 초기 라우팅 그룹 커넥터에 원본 서버와 대상 서버를 추가하여 중복을 제공할 수 있습니다. 자세한 내용은 TechNet Magazine의 이번 호에서 Exchange 관리 셸에 관한 David Strome의 기사를 참조하십시오.

일부 사서함 이동 준비
다음 단계는 Exchange 2003 서버에서 Exchange 2007 서버로 일부 사서함을 이동하는 것입니다. Move-Mailbox cmdlet을 사용하여 이 작업을 수행할 수 있습니다. 그러나 Exchange 2003 서버의 역할을 해제하려면 먼저 Exchange 2007 서버에 송신 커넥터와 수신 커넥터를 만들어 외부 SMTP 주소 공간으로의 라우팅을 처리하기 위해 Exchange 2003 서버에 정의된 SMTP 커넥터를 바꿔야 합니다.
다음 그림에서는 아카풀코 라우팅 그룹의 리소스가 Exchange 2007로 이동했습니다. 아카풀코 라우팅 그룹의 역할을 해제할 수 있지만 이렇게 하려면 지금 다른 라우팅 그룹으로 향하는 라우팅 그룹 커넥터를 설정해야 합니다. 그림 3에서는 마이애미 북부 라우팅 그룹의 브리지헤드 서버에 대한 라우팅 그룹 커넥터를 구성했습니다.
그림 3 라우팅 그룹 커넥터 구성
그림 3 라우팅 그룹 커넥터 구성 (더 작게 보려면 이미지를 클릭하십시오.)
그림 3 라우팅 그룹 커넥터 구성
그림 3 라우팅 그룹 커넥터 구성 (더 크게 보려면 이미지를 클릭하십시오.)
계속해서 LA 동부 라우팅 그룹을 Exchange 2007로 전환해 보겠습니다. 이 상황은 라우팅을 유지 관리하기가 약간 까다로운 유형입니다. 그림 4에서는 로스앤젤레스 사이트에 Exchange 2007이 설치되었고 두 번째 라우팅 그룹의 역할이 해제되었지만 추가로 생성된 라우팅 그룹 커넥터는 없습니다.
그림 4 로스앤젤레스 사이트에 설치된 Exchange 2007
그림 4 로스앤젤레스 사이트에 설치된 Exchange 2007 (더 작게 보려면 이미지를 클릭하십시오.)
그림 4 로스앤젤레스 사이트에 설치된 Exchange 2007
그림 4 로스앤젤레스 사이트에 설치된 Exchange 2007 (더 크게 보려면 이미지를 클릭하십시오.)
이제 로스앤젤레스 사이트의 Exchange 2007 서버에서 LA 서부 라우팅 그룹의 Exchange 2003 서버로 메시지를 보내면 메시지는 아카풀코, 마이애미 북부, 마이애미 남부의 순서로 릴레이된 다음 최종적으로 LA 서부에 도달합니다. LA 서부 라우팅 그룹의 Exchange 2003 서버에서 로스앤젤레스 사이트의 Exchange 2007 서버로 메시지를 보내면 메시지가 마이애미 남부, 마이애미 북부, 아카풀코의 순서로 릴레이된 다음 최종적으로 로스앤젤레스에 다시 도달하고 맙니다.
이를 피하려면 두 번째 라우팅 그룹 커넥터를 추가해야 합니다. 그림 5에서는 LA 서부에젤레스 사이트에 있는 Exchange 2007 서버로의 라우팅 그룹 커넥터를 추가하는 것을 보여 줍니다. 참고: 라우팅 그룹 커넥터가 너무 많아지지 않도록 하려면 첫 번째 라우팅 그룹 커넥터가 잘 연결된 허브 Active Directory 사이트에서 구성되었는지 확인하십시오.
그림 5 보다 효율적인 라우팅
그림 5 보다 효율적인 라우팅 (더 작게 보려면 이미지를 클릭하십시오.)
그림 5 보다 효율적인 라우팅
그림 5 보다 효율적인 라우팅 (더 크게 보려면 이미지를 클릭하십시오.)
이렇게 하면 즉시 확인하지 못할 수 있는 문제가 발생합니다. 이제 두 가지 이상의 방법으로 Exchange 2007 라우팅 그룹에 들어가거나 Exchange 2007 라우팅 그룹에서 나올 수 있습니다. Exchange 2007 라우팅 그룹은 링크 상태를 사용하지 않으므로 이제 잠재적 라우팅 루프가 존재합니다. Exchange 2003 서버는 연결이 끊긴 커넥터를 우회하는 대체 경로를 선택할 수도 있지만 Exchange 2007은 항상 비용이 가장 낮은 경로를 선택합니다. 이 문제를 해결하는 방법은 부분 링크 상태 업데이트 메시지를 억제하는 것입니다. 이렇게 하면 연결이 끊긴 커넥터 상태를 알려 주는 링크 상태 메시지는 허용되지만 구성 변경 내용을 알려 주는 링크 상태 메시지는 허용되지 않습니다. 이것이 중요한 이유는 Exchange 2003 서버가 새 라우팅 그룹 커넥터에 대해서는 알아야 하지만 대체 경로 계산을 시도해서는 안 되기 때문입니다. 최종 결과는 Exchange 2003 서버에 Exchange 2007 서버와 같은 장애 지점에서 대기(Queue-at-Point-of-Failure) 동작이 발생하는 것입니다.
그림 6에서는 더 많은 Exchange 2003 리소스가 Exchange 2007로 전환된 것을 보여 줍니다. 링크 상태 업데이트를 억제했으며 논리적 라우팅 경로를 유지 관리하는 라우팅 그룹 커넥터를 주의 깊게 설정했습니다.
그림 6 더 많은 Exchange 2003 리소스를 Exchange 2007로 이동
그림 6 더 많은 Exchange 2003 리소스를 Exchange 2007로 이동 (더 작게 보려면 이미지를 클릭하십시오.)
그림 6 더 많은 Exchange 2003 리소스를 Exchange 2007로 이동
그림 6 더 많은 Exchange 2003 리소스를 Exchange 2007로 이동 (더 크게 보려면 이미지를 클릭하십시오.)
그러나 여전히 문제가 남아 있습니다. 레드먼드와 밴쿠버에 링크 상태 섬(Link-state island)을 만들었습니다. 메일이 마이애미를 통과하여 잘 흐를 수는 있지만 레드먼드와 마이애미의 경우 링크 상태 구성 변경 내용을 알릴 방법이 없습니다. 현재 라우팅 테이블을 유지 관리하려면 레드먼드와 밴쿠버 간에 다른 라우팅 그룹 커넥터를 구성해야 합니다. 이 라우팅 그룹 커넥터의 비용을 충분히 높여서 Exchange 2003이 이 연결에서는 라우팅을 하지 못하도록 차단하면서 링크 상태 구성 변경 내용은 여전히 알려지도록 할 수 있습니다.
신중하게 계획한다면 개별적인 두 개의 Exchange 라우팅 토폴로지를 유지 관리하는 데 따른 문제를 피할 수 있습니다. Exchange 2007 서버만 실행하게 될 때까지 한 번에 하나씩 라우팅 그룹을 전환함으로써 가장 매끄러운 결과를 얻게 됩니다.
지금까지 Exchange 2007의 라우팅 변경 내용과 이러한 변경이 전환에 미치는 영향을 중심으로 살펴봤습니다. Exchange 2007로의 이동을 계획할 때 염두에 두어야 할 다른 고려 사항이 몇 가지 있습니다.
Exchange 2003 프런트 엔드 서버는 Exchange 2007 사서함에 액세스할 수 없습니다. 그러나 Exchange 2007 클라이언트 액세스 서버는 Exchange 2003 사서함에 연결하는 데 아무 문제가 없습니다. Exchange 2007 클라이언트 액세스 서버를 사용할 때는 사서함이 저장된 사서함 서버와 동일한 OWA 버전만 보게 됩니다. 개별 하드웨어에 Exchange 2007을 배포할 경우에는 클라이언트 액세스 서버가 Active Directory 사이트에 도입하는 첫 번째 역할이어야 합니다. 사서함을 Exchange 2007로 이동하기 전에 사서함에 대한 공용 인터넷 액세스를 제공하는 Exchange 2003 프런트 엔드 서버를 Exchange 2007 클라이언트 액세스 서버로 바꿔야 합니다.
사서함 서버 역할이 포함된 각 사이트에는 클라이언트 액세스 서버 역할(MAPI가 아닌 다른 클라이언트가 있는 경우. 그러나 오늘날 OWA를 사용하지 않는 사람은 별로 없을 것입니다.)과 Hub 전송 서버가 필요하다고 언급했습니다. 따라서 서버 역할이 하드웨어를 공유하도록 할 경우에는 역할 선택 항목에 클라이언트 액세스 서버를 포함해야 합니다. 일반적인 설치에는 Hub 전송 서버 역할, 클라이언트 액세스 서버 역할 및 사서함 서버 역할이 포함됩니다. 이 모든 역할은 Exchange의 모든 기능이 작동하도록 하는 데 필요합니다.
전환 프로세스에 대해 고려해야 할 또 다른 사항은 클라이언트 응용 프로그램(Outlook)을 업그레이드하는 시기입니다. 클라이언트를 Outlook 2007로 업그레이드해야만 Exchange 2007 서버의 모든 기능을 제대로 이용할 수 있습니다. 여기에는 향상된 부재 중 메시지 설정과 관리된 사서함 폴더 기능이 포함됩니다.
또한 Edge 전송 서버 역할을 배포할 시기를 결정해야 합니다. 기술적인 측면에서 볼 때 다른 Exchange 2007 서버 역할을 도입하기 전후에 현재 경계 네트워크 SMTP 릴레이 및 스마트 호스트를 Edge 전송 서버로 대체할 수 있습니다. 그러나 Edge 전송 서버를 먼저 배포하면 Exchange 2003이 Edge 전송 서버에 필요한 받는 사람 및 구성 데이터를 Active Directory에서 ADAM(Active Directory Application Mode)으로 복제할 방법이 없기 때문에 전반적인 기능이 제한됩니다.
적어도 하나의 Hub 전송 서버를 설치한 경우에는 경계 네트워크에 Edge 전송 서버를 배포한 다음 Hub 전송 서버가 있는 Active Directory 사이트에 Edge 전송 서버를 가입할 수 있습니다. Hub 전송 서버의 EdgeSync 서비스는 Active Directory에 있는 받는 사람 데이터의 하위 집합을 ADAM에 복제합니다.
이 데이터를 사용하면 Edge 전송 서버가 받는 사람 조회 및 수신 허용 목록 집계를 수행할 수 있으므로 Edge 전송 서버에서 실행되는 스팸 방지 에이전트를 최대한 활용할 수 있습니다. 또한 EdgeSync는 Exchange 조직과 인터넷 사이의 종단 간 메일 흐름에 필요한 송신 커넥터를 만듭니다. 따라서 외부 주소 공간으로의 라우팅을 제공하는 Exchange 2003 SMTP 커넥터를 대체하는 프로세스가 단순해질 수 있습니다.
충분한 시간을 두고 Exchange 2007로의 전환을 계획하면 수월한 경로를 통해 문제 없이 목표를 달성할 수 있음을 알게 됩니다.

Kate Follis는 Exchange 2007 기술 문서 작성 팀의 선임 콘텐츠 게시자이며 Edge 전송 및 Hub 전송 서버 역할을 전문적으로 담당하는 그룹을 이끌고 있습니다. Kate는 Microsoft에 근무하기 전에 수년 동안 Exchange와 Active Directory를 가르치는 MCT(Microsoft Certified Trainer)로 근무했습니다.
© 2007 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..


 Exchange Server 2007: Exchange 관리 셸을 통한 명령 수행
Exchange Server 2007 David Strome

Exchange 관리 셸을 통한 명령 수행
한 눈에 보기:
  • Exchange 관리 셸의 작동 원리
  • cmdlet 사용 방법
  • cmdlet와 명령 비교

Exchange 환경 관리자라면 새로 출시될 Exchange Server 2007에 Exchange 관리 셸이라는 새 명령줄 인터페이스가 포함되어 있다는 소식을 들었을 것입니다. Microsoft Windows PowerShell 기술을 기반으로 하는 Exchange 관리 셸은
Exchange Server 2007의 모든 기능을 명령줄에서 관리할 수 있는 강력한 관리 인터페이스입니다. 이 인터페이스를 통해 Exchange 관리 셸과 직접 상호 작용하거나, 자동화를 위한 스크립트를 작성하거나, 응용 프로그램을 기본 엔진과 통합할 수 있습니다. 그림 1은 작동 중인 셸을 보여 줍니다.
그림 1 Exchange 관리 셸
그림 1 Exchange 관리 셸 (더 작게 보려면 이미지를 클릭하십시오.)
그림 1 Exchange 관리 셸
그림 1 Exchange 관리 셸 (더 크게 보려면 이미지를 클릭하십시오.)
Exchange 관리 콘솔에서는 작업을 수행할 때 Exchange 관리 셸을 사용할 뿐 아니라, 마법사를 통해 수행 중인 명령을 보여 줍니다. 마법사가 만든 명령을 복사해서 명령줄이나 스크립트에 직접 붙여 넣으십시오. 원하는 대로 매개 변수를 수정한 후 WhatIf 매개 변수를 사용하여 스크립트나 명령을 테스트하면 환경을 변경하기 전에 미리 결과를 확인할 수 있습니다.
Exchange 관리 셸은 현재의 스크립트 솔루션과 통합할 수 있는 강력하고 융통성 있는 스크립트 플랫폼을 제공하며 COM이나 WMI(Windows Management Instrumentation) 같은 데이터 원본과 자유자재로 통신할 수 있는 기능을 제공합니다. .NET Framework를 기반으로 하는 Exchange 관리 셸에서는 Exchange 관리 셸의 최소 기능 단위인 cmdlet를 사용하여 일반 텍스트가 아닌 구조화된 데이터를 받고 반환합니다. 먼저 cmdlet에 대해 좀 더 자세히 살펴보겠습니다.

Windows PowerShell 스냅인
Exchange 관리 셸을 이해하기 위해서는 먼저 Exchange 관리 셸이 .NET Framework 기반의 융통성 있고 강력한 새 명령줄 인터페이스인 Windows PowerShell™과 어떤 관련이 있는지 알아야 합니다. 여러 다른 셸의 우수한 기능에 새 기능까지 추가된 Windows PowerShell은 다른 응용 프로그램에 대한 호스트로 작동하도록 설계되었는데, 이 작동 방식은 MMC(Microsoft Management Console)가 응용 프로그램과 함께 제공되는 다양한 스냅인에 대한 호스트로 작동하는 것과 거의 동일한 방식입니다. Exchange 관리 셸은 최초로 릴리스되는 Windows PowerShell 스냅인입니다.
스냅인은 응용 프로그램이나 주요 구성 요소를 관리하는 데 사용되는 cmdlet의 모음입니다. 스냅인을 사용하려면 먼저 로드해야 합니다. 다행히 Exchange 관리 셸 스냅인은 시작하기가 아주 쉽습니다. 그러나 시작 방법을 설명하기 전에 이 문서를 이해하고 Exchange 관리 셸을 사용하는 데 필요한 몇 가지 주요 개념을 먼저 짚고 넘어가겠습니다.
cmdlet - cmdlet는 다른 셸에서 기본적으로 제공되는 명령(예: cmd.exe의 dir 명령)과 비슷합니다. 익숙한 이런 명령들과 마찬가지로 cmdlet는 Exchange 관리 셸의 명령줄에서 직접 호출하여 별도의 프로세스가 아닌 셸 컨텍스트에서 실행할 수 있습니다. 하지만 다른 셸의 명령과는 달리 cmdlet의 이름은 그 기능을 쉽게 알 수 있는 동사-명사 형식입니다. 동사는 cmdlet가 수행하는 작업을 설명하고 명사는 작업의 대상이 되는 구성 요소나 기능을 설명합니다.
cmdlet가 수행하는 작업을 추측할 필요가 전혀 없습니다. 예를 들어 Move-Mailbox cmdlet를 보기만 하면 그 용도를 바로 파악할 수 있습니다.
cmdlet가 일반 명령과 어떻게 다른지 보려면 보조 기사의 "cmdlet와 명령 비교"를 참조하십시오. 이 문서는 Windows® SDK의 .NET Framework 3.0 섹션에서 발췌한 것으로 windowssdk.msdn.microsoft.com/en-us/library/ms714395.aspx(영문)에서 확인할 수 있습니다.
Identity 및 위치 매개 변수 - Identity 매개 변수는 대부분의 Exchange 관련 cmdlet에서 사용할 수 있습니다. Exchange Server 2007의 특정 개체를 참조하는 고유 식별자에 대한 액세스를 제공하는 이 매개 변수를 사용하면 원하는 고유 값을 사용하여 특정 Exchange 개체에 대한 작업을 수행할 수 있습니다.
Identity 매개 변수는 다른 매개 변수 값의 모음입니다. 이러한 값은 해당 개체 집합 내에서 고유합니다. 이러한 매개 변수에는 사용자가 지정할 수 있는 매개 변수(예: Name 및 DistinguishedName)와 시스템에 의해 생성되는 매개 변수(예: GUID)가 있습니다. 사용되는 추가 매개 변수(있는 경우) 및 이 매개 변수가 채워지는 방법은 참조하는 개체에 따라 달라집니다.
또한 Identity 매개 변수는 이름을 지정하지 않고 값을 지정할 수 있는 위치 매개 변수로도 사용할 수 있습니다. Parameter Position 특성이 정수인 매개 변수는 위치 매개 변수입니다. 이 정수는 cmdlet가 명령줄에서 매개 변수의 값을 찾는 위치를 나타냅니다. Identity는 첫 번째 위치인 위치 0에 있는 위치 매개 변수이므로, 매개 변수 이름 없이 이 위치에 입력된 값은 Identity 매개 변수 값으로 간주됩니다. 따라서 명령을 입력할 때 키 입력 횟수가 줄어듭니다. 예를 들어 다음 명령은
Get-Mailbox –Identity "Kim Akers"
다음 명령과 동일한 작업을 수행합니다.
Get-Mailbox "Kim Akers"
파이프라인 - Exchange 관리 셸에서의 파이프라인은 작업을 수행할 때 다른 cmdlet의 출력을 사용하는 cmdlet의 동작을 말합니다. 파이프라인에는 파이프("|") 기호가 사용됩니다. 동일한 명사 cmdlet 집합에 속해 있는 모든 동사는 파이프로 연결된 다른 명령의 정보를 사용할 수 있습니다. 일부 명사 cmdlet 집합의 경우에는 파이프라인을 통해 데이터를 다른 명사 cmdlet 집합에 전달할 수도 있습니다.
두 개 이상의 cmdlet를 파이프라인으로 연결하여 사용하면 적은 수의 구성 요소로 매우 효과적인 작업을 수행할 수 있습니다. 예를 들어 첫 번째 cmdlet로 데이터를 수집하고, 수집된 데이터를 두 번째 cmdlet에 전달하여 하위 집합으로 필터링한 다음 하위 집합을 세 번째 cmdlet에 전달하여 하위 집합에 대한 작업을 수행할 수 있습니다.

Exchange 관리 셸 시작
셸을 로드하는 가장 간단한 방법은 시작, 프로그램, Microsoft Exchange Server 2007, Exchange 관리 셸을 차례로 클릭하는 것입니다.
또한 Exchange 관리 셸 스냅인은 Windows PowerShell 세션에서 수동으로 로드할 수도 있습니다. 시작, 프로그램, Windows PowerShell을 차례로 클릭합니다. 프로그램이 시작되면 다음 명령을 실행하여 Exchange 관리 셸을 로드합니다.
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin
프로그램 메뉴 항목을 사용하여 Exchange 관리 셸 스냅인을 로드하는 방법과 Add-PSSnapin cmdlet를 사용하여 스냅인을 수동으로 시작하는 방법 사이에는 약간의 차이가 있습니다. 프로그램 메뉴 항목을 사용하면 Exchange 관리 셸 스냅인이 로드되는 동시에 Windows PowerShell 스크립트가 실행되면서 사용자 지정된 Exchange 관리 환경이 설정됩니다. 수동으로 Exchange 관리 셸을 로드한 후 비슷한 관리 환경을 설정하려면 Exchange 설치의 bin 디렉터리(예: C:\Program Files\Microsoft\Exchange Server\Bin)로 가서 다음 명령을 실행합니다.
.\Exchange.ps1
Exchange.ps1 스크립트를 자세히 보면 Windows PowerShell 환경을 요구에 맞게 사용자 지정하는 방법을 알 수 있습니다. Exchange 관리 셸이 로드되면 그림 2와 비슷한 화면이 표시됩니다.
그림 2 Exchange 관리 셸 시작 배너
그림 2 Exchange 관리 셸 시작 배너 (더 작게 보려면 이미지를 클릭하십시오.)
그림 2 Exchange 관리 셸 시작 배너
그림 2 Exchange 관리 셸 시작 배너 (더 크게 보려면 이미지를 클릭하십시오.)

시작하기
셸에는 매우 많은 cmdlet로 이루어진 커다란 배열이 있기 때문에 Get-Help cmdlet와 Exchange Server 2007 도움말 파일이 아주 유용합니다. Exchange Server 2007 도움말 파일의 Operations(작업) 단원에서는 대부분의 관리 작업의 수행 방법을 설명한 수십 개의 절차를 제공합니다.
Get-Help만을 입력하면 도움말을 얻는 데 필요한 일반적인 도움말 정보가 표시됩니다. 특정 cmdlet에 대한 도움말을 보려면 Get-Help 뒤에 정보가 필요한 cmdlet를 입력하면 됩니다. Detailed, Full 및 Example 매개 변수를 사용하여 표시되는 정보를 제어할 수 있습니다. 명령 끝에 매개 변수를 추가하기만 하면 됩니다. 예를 들어 Get-Help cmdlet name –Full을 입력하면 해당 cmdlet와 관련된 모든 도움말 단원이 반환됩니다.
cmdlet의 특정 매개 변수에 대한 정보를 검색하려면 Parameters 매개 변수를 Get-Help와 함께 사용합니다. 예를 들어 "quota"가 포함된 Set-Mailbox cmdlet의 모든 매개 변수와 설명을 보려면 다음 명령을 사용합니다.
Get-Help Set-Mailbox –Parameter *quota*
특정 서버 역할 또는 구성 요소 기능을 관리하거나, 특정 범위의 기능을 수행하는 개체에 영향을 주는 cmdlet 목록을 볼 수도 있습니다. Get-Help cmdlet을 Role, Component 및 Functionality의 세 매개 변수와 함께 사용하면 이 작업을 수행할 수 있습니다. Get-Help cmdlet에서 이러한 매개 변수를 사용할 때는 매개 변수의 값을 와일드카드 문자 "*"로 묶어야 합니다. 다음은 각 매개 변수를 사용하여 Get-Help를 호출하는 방법을 보여 주는 예입니다.
Get-Help -Role *Mailbox*
Get-Help -Component *Recipient*
Get-Help -Functionality *Server*
자세한 내용은 사용할 수 있는 모든 역할, 구성 요소 및 기능 값이 설명되어 있는 Exchange Server 2007 도움말 파일의 "Getting Help(도움말 보기)" 항목을 참조하십시오.

명령 출력의 서식 지정
기본적으로 Exchange 관리 셸에서는 출력을 화면에 표시할 때 각 개체의 사용 가능한 속성 중 일부만 표시합니다. 그러나 명령의 출력을 Format-List, Format-Table 및 Format-Wide라는 세 가지 서식 지정 cmdlet에 파이프로 연결하면 모든 속성에 쉽게 액세스할 수 있습니다. Format-List와 Format-Table은 자주 사용할 가능성이 크므로 지금부터 이들 cmdlet에 대해 구체적으로 설명하겠습니다.
Format-List cmdlet는 파이프라인을 통해 입력을 받은 다음 각 개체의 지정된 모든 속성을 세로 열 목록 형식으로 출력합니다. Property 매개 변수는 매개 변수 이름이 아니라 값을 지정해야 하는 위치 매개 변수이기는 하지만, 이 Property 매개 변수를 사용하여 표시하려는 속성을 지정할 수 있습니다. 매개 변수를 지정하지 않고 Format-List cmdlet를 호출하면 모든 속성이 출력됩니다. 이 cmdlet는 출력을 잘라내지 않고 여러 줄로 표시합니다. Format-List를 효과적으로 사용하는 방법 중 하나는 cmdlet의 기본 출력을 다시 정의하여 추가 정보 또는 중요한 정보를 검색하는 것입니다. 예를 들면 다음과 같은 명령을 실행할 수 있습니다.
Get-DistributionGroup | Format-List Name, *OnlyFrom,
PrimarySmtpAddress, *Size*
그림 3은 이 명령의 출력을 보여 줍니다.
그림 3 Format-List 출력 예
그림 3 Format-List 출력 예 (더 작게 보려면 이미지를 클릭하십시오.)
그림 3 Format-List 출력 예
그림 3 Format-List 출력 예 (더 크게 보려면 이미지를 클릭하십시오.)
Format-Table cmdlet를 사용하면 속성 데이터 열과 레이블 머리글로 구성된 표 형식으로 항목을 표시할 수 있습니다. Get-Mailbox나 Get-JournalRule 등의 많은 cmdlet에서는 기본적으로 표 형식의 출력을 사용합니다. Format-Table cmdlet의 매개 변수에는 Properties 및 GroupBy 매개 변수가 있습니다. 이들 매개 변수는 Format-List cmdlet와 똑같은 방식으로 작동합니다. 속성 정보를 줄 끝에서 잘라내지 않고 전체 정보를 여러 줄로 표시하려면 다음과 같이 Wrap 매개 변수를 사용합니다.
Get-Mailbox –Database Research | Format-Table Name,
ProhibitSendQuota, Database –Wrap
출력을 보려면 그림 4를 참조하십시오.
그림 4 Format-Table 출력 예
그림 4 Format-Table 출력 예 (더 작게 보려면 이미지를 클릭하십시오.)
그림 4 Format-Table 출력 예
그림 4 Format-Table 출력 예 (더 크게 보려면 이미지를 클릭하십시오.)
와일드카드 문자를 사용하면 각 속성 이름을 개별적으로 입력하지 않고도 여러 속성을 찾을 수 있습니다. 예를 들어 다음 명령은 E-mail로 시작되는 모든 속성을 반환합니다.
Get-Mailbox | Format-List Email*

실습
지금까지 살펴본 기본 명령을 활용하는 몇 가지 예를 살펴보겠습니다. 이러한 예를 통해 Exchange 관리 셸의 성능과 유연성을 확인하고 사용 방법을 익힐 수 있습니다.
먼저 User1부터 User10까지 총 10명의 사용자를 만드는 명령을 실행합니다.
1..10 | ForEach { Net User "User$_" MyPassword=01 /ADD
/Domain; Enable-Mailbox "User$_" -Database "Mailbox
Database" }
한 부분씩 살펴보겠습니다. 1..10 명령은 1부터 10까지의 정수를 출력한 다음 파이프라인을 통해 이러한 정수를 ForEach cmdlet에 전달합니다. 정수를 받은 ForEach cmdlet는 각 개체에 대해 중괄호 { } 안에 있는 명령을 실행합니다. Net User 명령은 새 도메인 사용자를 만들고, Enable-Mailbox cmdlet는 로컬 서버의 "Mailbox Database"에 새 사서함을 만듭니다. 세미콜론을 사용해서 두 명령을 분리할 수 있으므로 한 명령줄에 여러 명령을 입력할 수 있습니다. $_ 변수는 파이프라인에 있는 현재 개체의 값을 갖는 특별한 변수입니다. 위 예의 경우 $_ 변수는 현재 파이프라인에 있는 정수 값을 갖습니다.
다음은 MBX 서버에 있는 사서함을 보고 각 사서함의 Name, Mailbox Database 및 quota 속성을 반환하는 예입니다.
Get-Mailbox –Server MBX | Format-Table
Name,Database,*quota*
Get-Mailbox cmdlet는 Server 매개 변수로 지정된 각 사서함을 반환한 다음 각 사서함 개체의 출력을 파이프라인을 통해 Format-Table cmdlet에 전달합니다. 표시할 속성을 지정하지 않은 경우 Format-Table cmdlet는 기본적으로 cmdlet에서 반환된 모든 속성을 표시합니다. 이 예에서는 Name 및 Database 속성과 문자열 "quota"가 포함된 모든 속성이 요청되었습니다. 그림 5는 출력 결과를 보여 줍니다.
그림 5 Get-Mailbox 명령 출력
그림 5 Get-Mailbox 명령 출력 (더 작게 보려면 이미지를 클릭하십시오.)
그림 5 Get-Mailbox 명령 출력
그림 5 Get-Mailbox 명령 출력 (더 크게 보려면 이미지를 클릭하십시오.)
다음 예에서는 전체 조직에서 메일 사용이 가능한, 직책이 "Manager(관리자)"인 모든 사용자의 전송 할당량 한도를 600MB로 설정합니다.
Get-User –Filter { Title –Like "*Manager*"}
–RecipientTypeDetails UserMailbox | Set-Mailbox
–ProhibitSendQuota 600MB
Get-User cmdlet는 아무 매개 변수 없이 실행하면 사서함을 사용할 수 없는 사용자가 포함된 Active Directory의 모든 사용자 개체를 반환합니다. Set-Mailbox cmdlet에서 사용할 수 있는 사용자 개체 집합을 검색하려면, Get-User cmdlet가 메일 사용이 가능한 사용자인 Active Directory 사용자 개체만을 반환해야 합니다. RecipientTypeDetails 매개 변수를 사용하여 Active Directory 받는 사람 형식을 지정할 수 있습니다(위 예의 경우 UserMailbox). 그런 다음 메일 사용이 가능한 직책이 관리자인 사용자 집합을 검색해야 합니다. 위 예의 경우 각 Active Directory 사용자 개체의 Title 속성이 채워져 있습니다. 조건에 맞는 Active Directory 개체만을 반환하도록 서버에 지시하는 Filter 매개 변수에 이 속성 값을 지정하여 관리자인 사용자를 찾을 수 있습니다. 이 기능을 서버 쪽 필터링이라고 합니다. 검색된 개체 집합은 Set-Mailbox cmdlet에 전달되며, 이 cmdlet는 각 사서함의 ProhibitSendQuota 속성을 600MB로 설정합니다.
이제 메일 그룹의 구성원인 모든 사서함을 제거하는 명령의 출력을 테스트할 차례입니다. 이 작업을 수행하는 명령은 다음과 같습니다.
Get-DistributionGroupMember "Fourth Year Students" |
 Where { $_.RecipientType –Eq "UserMailbox" } | Remove-
 Mailbox -WhatIf
첫 번째 cmdlet에서는 Fourth Year Students 메일 그룹의 구성원인 받는 사람 개체가 검색됩니다. 그런 다음 RecipientType이 "UserMailbox"인 받는 사람 개체만 Remove-Mailbox cmdlet에 전달됩니다. Remove-Mailbox cmdlet는 사서함을 제거하지 않고 수행할 작업과 작업 대상 개체를 표시하기만 합니다. Get-DistributionGroupMember cmdlet에서는 "Fourth Year Students" 메일 그룹의 구성원인 모든 받는 사람 개체 목록이 검색됩니다. 그러나 Remove-Mailbox cmdlet는 메일 사용이 가능한 사용자에 대해서만 작동하므로 필터링을 통해 "UserMailbox" 이외의 모든 받는 사람 유형을 제거해야 합니다. 다른 cmdlet와 달리 Get-DistributionGroupMember cmdlet에는 Filter cmdlet가 없으므로 서버 쪽 필터링을 수행할 수 없습니다. 성능 면에서 이점이 없기 때문에 서버 쪽 필터링을 수행할 수 없는 cmdlet의 경우 Where cmdlet를 사용하여 클라이언트 쪽 필터링을 수행할 수 있습니다. 클라이언트 쪽 필터링은 로컬 클라이언트 시스템에서 모든 개체를 검색하여 필터링을 수행합니다. Where cmdlet는 사용자가 지정한 조건에 맞는 개체만 통과할 수 있게 합니다. RecipientType이 "UserMailbox"인 개체가 Remove-Mailbox cmdlet에 전달됩니다. 이 cmdlet는 Active Directory 사용자 개체를 제거하고 해당 사서함을 제거하도록 표시합니다. WhatIf 매개 변수를 사용할 경우 Remove-Mailbox cmdlet는 다음과 비슷한 텍스트를 표시합니다.
What if: Removing the Mailbox "contoso.com/Users
/user10" will remove the Windows user object and mark
the mailbox in the database for removal.
명령이 원하는 대로 실행되었다고 생각되면 WhatIf 없이 명령을 다시 실행합니다. 특정 cmdlet의 경우(예: Remove 동사가 있는 cmdlet) 변경 내용이 적용되기 전에 셸에서 자동으로 확인을 요청합니다. 각 변경 내용을 단계별로 수행하거나, 확인 메시지가 셸에 다시 표시되지 않도록 하거나, 이후의 처리를 취소할 수 있는 옵션이 제공됩니다. 자동 확인이 구현되지 않은 cmdlet의 경우 Confirm 매개 변수를 사용하여 강제로 확인 메시지를 표시할 수 있습니다.

결론
잠깐이지만 cmdlet의 강력함을 맛볼 수 있었을 것입니다. 이제부터는 스스로 경험을 통해 Exchange 관리 셸과 Microsoft Windows PowerShell이 시스템 관리 작업에 얼마나 유용한지 확인할 수 있을 것입니다. 두 항목에 대한 보다 자세한 내용을 보려면 다음 리소스를 참조하십시오. 관리 셸에 대해서는 Exchange Server 2007 도움말 파일(go.microsoft.com/fwlink/?LinkId=69434)(영문), Windows Powershell 스크립트 센터(go.microsoft.com/fwlink/?LinkId=71134) 및 Exchange 팀 블로그(msexchangeteam.com)(영문)를 참조하십시오.

David Strome은 Microsoft의 Exchange User Education 그룹에서 1년 이상 활동하고 있는 테크니컬 라이터입니다. 워싱턴 주 레드먼드에 있는 Microsoft에 입사하기 전에는 캐나다의 브리티시 컬럼비아 주에 있는 여러 회사에서 약 10년 동안 Exchange Server 설치의 디자인, 구현 및 관리 업무를 수행했습니다. 문의 사항이 있으면 dstrome@microsoft.com으로 연락하십시오.


 Exchange Server 2007: Exchange &amp; Outlook: 더 나아진 통합
Exchange Server 2007 Michael Khalili

Exchange & Outlook: 더 나아진 통합
한 눈에 보기:
  • 간편해진 설치
  • 음성, 팩스, 전자 메일 통합
  • 규칙 준수를 위한 관리 폴더

지난 수년 간 많은 사용자들은 Microsoft Exchange Server 및 Outlook을 사용하여 안전성 있는 전자 메일을 사용하고 일정 통합 및 관리는 물론 손쉽게 연락처를 구성할 수 있었습니다. 일부 사용자의 경우 이 두 프로그램의 조합이 더 이상 어떻게 새로워질 수 있다는 것인지 의아해할지도 모릅니다. 그러나 곧 출시되는 Exchange Server 2007
및 Microsoft Office Outlook 2007에서는 비약적으로 개선된 통신 및 공동 작업 기능을 제공합니다.
Outlook 클라이언트를 시작하는 순간부터 Exchange Server 2007 및 Office Outlook® 2007에서 제공하는 향상된 기능을 체험할 수 있습니다. 이전 버전의 Outlook에서는 사용자가 직접 Exchange 사서함 서버 이름을 알아야 했으므로 많은 사용자들이 어려움을 겪었습니다. 이로 인해 헬프 데스크 지원 요청이 잦아지거나 초기화 스크립트가 복잡해져 비용이 증가하고 효율적인 메시징 환경을 실행하는 것이 어려워졌습니다. 하지만 이제는 클라이언트가 도메인에 가입된 경우 Exchange Autodiscover 웹 서비스를 통해 Outlook에서 자동으로 해당 계정을 구성할 수 있습니다. 클라이언트가 도메인에 가입되어 있지 않은 경우 사용자는 이름, 전자 메일 주소, 암호만 입력하면 나머지 과정은 Outlook 및 Exchange에서 자동으로 구성합니다(그림 1 참조).
그림 1 계정 설치
그림 1 계정 설치 (더 작게 보려면 이미지를 클릭하십시오.)
그림 1 계정 설치
그림 1 계정 설치 (더 크게 보려면 이미지를 클릭하십시오.)
이전에는 Outlook을 처음 사용하려면 사용자가 직접 Outlook을 설치해야 했을 뿐 아니라 다른 메일 서버로 이동하는 경우 매번 다시 설정해야 했습니다. 사서함 마이그레이션을 곧 앞두고 이에 대한 경고 메일이 사용자에게 전송되어도, 업무에 바쁜 사용자는 이에 신경을 쓸 여력이 없었습니다. 어느 날 Outlook이 잠겨 있다는 걸 알기 전까지는 말입니다. 이 역시 헬프 데스크에 지원 요청 문의가 잇따르는 문제이며 Autodiscover 웹 서비스로 이를 해결할 수 있습니다. 사용자가 사서함 서버를 다른 서버로 이동한 경우 Outlook에서는 이전 구성을 더 이상 사용할 수 없다는 것을 인식하여 Autodiscover 웹 서비스에 쿼리를 보내 새로운 사서함에 대한 클라이언트를 재구성합니다. 모든 프로세스는 최종 사용자 모르게 수행됩니다.

일정 논리 재구성
이전에는 대부분의 일정 논리가 Outlook에 있었습니다. 모임 업데이트는 개별 모임 초대로 처리되었으므로 알림이 고장 난 것으로 인식될 수도 있었습니다. 모임 업데이트 두 개를 연속적으로 보낸 경우, 받는 사람이 첫 번째 모임 업데이트보다 두 번째 모임 업데이트를 먼저 받으면 일정에 날짜가 지난 정보가 있다고 생각할 수 있었습니다. 그리고 Smartphone 또는 PDA를 통해 Outlook 정보에 액세스하는 경우, 데이터를 보는 사용자 방식에 따라 약속 있음/없음 정보가 달라질 수 있었습니다.
이러한 문제는 Outlook 클라이언트에서 Exchange Server 2007로 모든 일정 논리를 이동하여 해결할 수 있었습니다. 서버에서 모임 요청을 받게 되면 사용자가 해당 약속을 수락 또는 거절하기 전까지 해당 모임은 일정에서 자동으로 미정으로 지정됩니다. 모임에 대한 시간이나 장소 변경 내용이 전송되면 해당 모임은 자동으로 업데이트되고 이전 초대는 날짜가 지난 것으로 표시되므로 사용자가 실수로 지난 일정을 수락하는 일을 방지할 수 있습니다. 이러한 논리는 Office Outlook, Outlook Web Access, Outlook Mobile 및 기타 타사의 클라이언트를 비롯한 모든 클라이언트에 동일하게 적용되므로 정확하고 최신 정보로 업데이트된 모임만 표시됩니다.
신뢰할 수 있는 정확한 일정 관리를 통해 생산성을 향상할 수 있는 새로운 도구 집합을 사용자에게 제공할 수 있게 되었습니다. 이전에는 여러 명의 바쁜 직원과 모임을 설정하는 것이 쉽지 않았습니다. 사용자는 모임을 주선하기 위해 일정 정보를 일일이 뒤져 가며 모든 참석자의 시간에 맞는 모임 시간을 직접 찾아야만 했습니다. 이제 Outlook 2007 Scheduling Assistant(일정 정리, 그림 2 참조)를 통해 모두의 시간에 맞는 최적의 시간대를 찾을 수 있습니다. 필수 참석자 및 선택 참석자를 입력한 다음 원하는 회의실 또는 리소스를 입력하면 일정 정리에 최적의 모임 시간이 색으로 구분되어 표시됩니다. 날짜를 선택하면 동일한 방식으로 해당 일에서 가장 적합한 시간대를 찾습니다.
그림 2 일정 정리
그림 2 일정 정리 (더 작게 보려면 이미지를 클릭하십시오.)
그림 2 일정 정리
그림 2 일정 정리 (더 크게 보려면 이미지를 클릭하십시오.)
일정 정리에서는 최적의 모임 시간을 결정하기 위해 필수 참석자를 우선적으로 검토하며 그 다음으로 선택 참석자, 그리고 마지막으로 회의실과 리소스를 검토합니다. 또한 일정 정리를 사용하면 유동적인 업무 시간 및 기타 다양한 시간대와 관련한 문제를 손쉽게 처리할 수 있습니다. 사용자는 매일 아침 출근 및 퇴근 시간을 지정하여 직접 업무 시간을 설정할 수 있습니다. 따라서 늦잠으로 인해 오전 9시에서 10시 전에 회사에 도착하지 못하는 사용자의 경우 이 시간부터 시작하도록 업무 시간을 설정할 수 있습니다. 모임 일정을 정할 때 오전 8시와 같은 이른 시각을 모임 시간으로 정하는 것은 바람직하지 않습니다. 예를 들어 한 그룹은 런던에 있고 나머지 한 그룹은 LA에 있어 서로 시차가 맞지 않는 경우를 생각해 보십시오. 이 두 그룹이 모임을 가질 시에는 서로의 업무 시간 중 겹치는 시간대를 선택해야 합니다. 런던 쪽 그룹에서 모임 시간을 늦은 오후로 잡으면 LA 쪽 그룹의 모임 시간은 이와 정반대인 새벽 2시가 됩니다.

짚 더미에서 바늘 찾기
지난 몇 년간 일반 사용자의 받은 편지함으로 수신되는 전자 메일 메시지 수는 놀라운 속도로 증가했습니다. 이전에는 회사에서 사용하는 사서함에 몇 백 개의 메시지만 저장되는 것이 보통이었지만 이제 몇몇 사용자는 하루에도 이 정도의 메시지를 수신합니다. 이처럼 홍수처럼 밀려오는 메시지에는 모든 비즈니스 작업에 있어 매우 중요한 정보가 많이 섞여 있습니다. 이러한 넘쳐나는 정보 속에 꼭 필요한 정보를 찾는 것이 중요한 과제로 떠올랐습니다.
Office Outlook 2007 및 Exchange Server 2007의 검색 기능은 이전 버전에 비해 상당히 개선되었습니다. 사용자가 캐시 모드에 있든 온라인 모드에 있든 상관없이 동일한 검색 알고리즘을 메시지에 적용할 수 있습니다. 온라인 모드에서는 검색이 실행되는 Exchange Server로 검색 쿼리가 보내집니다. Exchange Server 2003의 인덱서보다 처리 속도가 35배나 빠른 Exchange Content Indexer를 사용하므로 메시지를 더욱 빨리 찾아 가져올 수 있습니다. 캐시 모드에서는 Outlook에서 Windows® 데스크톱 검색 3.0 기반의 빠른 검색을 사용하므로 인덱싱 엔진을 통합하고 CPU 시간을 절약할 수 있습니다. 검색 작업 시 그림 3과 같이 subject(제목), body(본문), to(받는 사람), from(보내는 사람) 필드뿐만 아니라 첨부 파일에 포함된 텍스트에 대해 검색을 수행합니다.
그림 3 중요한 전자 메일 메시지를 검색할 수 있는 새로운 방법
그림 3 중요한 전자 메일 메시지를 검색할 수 있는 새로운 방법 (더 작게 보려면 이미지를 클릭하십시오.)
그림 3 중요한 전자 메일 메시지를 검색할 수 있는 새로운 방법
그림 3 중요한 전자 메일 메시지를 검색할 수 있는 새로운 방법 (더 크게 보려면 이미지를 클릭하십시오.)

통합 메시징을 사용하여 어디서든 액세스 가능
Exchange 통합 메시징은 Exchange Server 2007에서 기본 제공되는 구성 요소로, 전자 메일, 음성 메일, 팩스 등을 비롯한 모든 유형의 비즈니스 통신을 단일 사서함으로 불러옵니다. 기존 시스템에서는 음성 메일은 전화를 통해, 전자 메일은 컴퓨터를 통해, 팩스는 전용 팩스 기계를 통해서만 사용할 수 있었습니다. 그러나 Exchange 통합 메시징을 사용하면 특정 시간 및 장소에서 필요에 따라 가장 적합한 클라이언트를 선택할 수 있습니다. Outlook에서는 받은 편지함의 전자 메일 메시지 바로 옆에 음성 및 팩스 메시지가 표시됩니다. 플레이어가 내장된 음성 메일 메시지를 선택하면 읽기 창에서 메시지가 바로 재생됩니다(그림 4 참조).
그림 4 Outlook에서 음성 메일 메시지 재생
그림 4 Outlook에서 음성 메일 메시지 재생 (더 작게 보려면 이미지를 클릭하십시오.)
그림 4 Outlook에서 음성 메일 메시지 재생
그림 4 Outlook에서 음성 메일 메시지 재생 (더 크게 보려면 이미지를 클릭하십시오.)
또한 Outlook에서는 상황에 맞게 메시지를 처리할 수 있습니다. 일반적으로 음성 메일을 듣는 경우 종이에 간단히 메모를 하게 됩니다. 이러한 메모는 메시지와 함께 두지 않으므로 분실할 수 있어 효율적인 통신에 도움이 되지 않습니다. Exchange 통합 메시징을 사용하면 Outlook에서 직접 메모를 작성할 수 있습니다. 이렇게 작성된 메모는 항상 음성 메일 메시지의 내용에 맞게 표시되도록 메시지와 함께 저장되며 검색 가능한 텍스트로 인덱싱됩니다. 따라서 Exchange Server 2007 및 Office Outlook 2007의 향상된 검색 기능을 사용하여 메모를 빠르게 찾을 수 있습니다.
Outlook에서는 클라이언트 내에서 음성 메일 PIN(개인 ID 번호)을 변경할 수 있을 뿐만 아니라 다양한 음성 메일 옵션(그림 5 참조)을 설정할 수 있습니다.PIN 설정은 음성 메일 시스템에서 가장 많은 헬프 데스크 지원 요청을 받았던 부분이기도 합니다. Outlook의 이러한 옵션을 통해 사용자는 전자 메일을 통해 새로 생성된 PIN을 부여받을 수 있습니다. 이 PIN을 사용하면 Exchange 통합 메시징 전화 인터페이스, Outlook Voice Access에 한 번에 액세스할 수 있습니다. 액세스하고 나면 PIN을 변경하라는 메시지가 표시됩니다.
그림 5 PIN 초기화를 비롯한 통합 메시징 옵션
그림 5 PIN 초기화를 비롯한 통합 메시징 옵션 (더 작게 보려면 이미지를 클릭하십시오.)
그림 5 PIN 초기화를 비롯한 통합 메시징 옵션
그림 5 PIN 초기화를 비롯한 통합 메시징 옵션 (더 크게 보려면 이미지를 클릭하십시오.)

보안 및 보호
오늘날의 조직은 메시징 환경에 대한 여러 위협에 직면해 있습니다. Outlook과 Exchange를 함께 사용하면 이러한 위협에 노출되지 않을 수 있습니다. Office Outlook 2007에서는 이러한 위협 중 하나인 스팸을 방지하기 위한 새로운 방법으로 Outlook 전자 메일 소인을 지원합니다. Outlook에서 보내는 메일에 대해 간단한 연산 퍼즐을 수행하고 해당 메시지에 이러한 퍼즐의 정답을 추가하면 Exchange에서는 결과를 확인합니다. 보통의 합법적인 메일에 이러한 연산 퍼즐을 한 번만 수행하는 경우에도 적지 않은 CPU 시간이 소요되므로, 스패머가 대량의 전자 메일을 보내려고 하는 경우 스패머 컴퓨터에서는 이러한 전자 메일에 대한 퍼즐을 만들어야 하므로 엄청난 과부하가 발생합니다. 따라서 Outlook 전자 메일 소인이 붙은 메시지는 소인이 없는 메시지에 비해 합법적인 메시지일 확률이 높아지는 것이며 Exchange에서는 이를 통해 각 전자 메일 메시지의 유효성 여부를 확인할 수 있습니다.
스팸과 같은 기존의 위협뿐만 아니라 새로운 규정 체제로 인해서도 메시징 시스템에 대한 요구 사항이 달라지고 있습니다. Sarbanes-Oxley, HIPPA, Basel II와 같은 규정에서는 기록의 보존 또는 파기에 대한 엄격한 규칙을 명시하고 있습니다. Exchange 및 Outlook에서는 새롭게 부각되고 있는 이러한 요구 사항을 충족하기 위해 Managed Folders(관리 폴더)를 도입했습니다. 관리자는 특정한 유형의 메시지에 대해 관리 폴더를 설정할 수 있습니다. Outlook에서는 관리 폴더에 저장되는 메시지 유형에 대한 설명과 함께 관리 폴더가 최종 사용자에게 표시됩니다(그림 6 참조). Exchange 전송 규칙을 사용하여 자동으로 메시지를 특정 폴더로 전송할 수도 있습니다. 관리 폴더를 사용하면 메시지에 해당 관리 폴더의 보관, 보존 및 파기에 대한 정책을 적용할 수 있으며 자동으로 조직의 정책을 일관성 있게 적용하여 메시지를 처리할 수 있습니다.
그림 6 관리 폴더를 통해 전자 메일에 대한 규칙 준수
그림 6 관리 폴더를 통해 전자 메일에 대한 규칙 준수 (더 작게 보려면 이미지를 클릭하십시오.)
그림 6 관리 폴더를 통해 전자 메일에 대한 규칙 준수
그림 6 관리 폴더를 통해 전자 메일에 대한 규칙 준수 (더 크게 보려면 이미지를 클릭하십시오.)
위와 같은 모든 노력에도 불구하고 때로 규칙 준수 위반 사례가 발생합니다. 이러한 경우에는 확인 및 복구 작업을 신속하게 수행해야 합니다. 규칙 준수 관리자의 경우 Exchange에서 제공하는 빠른 검색을 사용하면 규칙 준수 위반을 일으킨 메시지를 쉽게 찾을 수 있습니다. 검색 작업은 위반 사항을 철저하게 찾아내서 수정할 수 있도록 사서함 전체에 대해 수행될 수 있습니다.

보다 관리가 용이한 환경
Exchange Server 2007 및 Office Outlook 2007을 함께 사용하면 이전 버전보다 크게 향상된 메시징 시스템을 이용할 수 있습니다. 중요한 비즈니스 통신을 한 자리에서 해결할 수 있고 검색 및 설정을 쉽게 수행할 수 있으며 보다 안전하고 호환성이 높은 환경에서 작업할 수 있습니다. 또한 보다 업그레이드된 공동 작업 및 통신 기능을 사용할 수도 있습니다.

Michael Khalili는 Exchange Server 제품 관리자로 클라이언트 액세스 및 통합 메시징을 담당하고 있습니다. 또한 기타 업무와 함께 Outlook-Exchange 통합 작업을 담당하고 있습니다.


 Exchange Server 2007: Exchange 2007을 사용한 중단 없는 연결
Exchange Server 2007 Joshua Trupin

Exchange 2007을 사용한 중단 없는 연결
한 눈에 보기:
  • Outlook Web Access의 개선된 기능
  • Exchange Server 2007의 통합 메시징
  • ISA Server 2006을 사용한 보안

몇 년 전만 해도 온라인 통신은 기초적인 수준이었습니다. POP3과 SMTP를 통해 전자 메일을 보냈으며, 그것만으로도 충분했습니다. 물론 변화가 필요합니다. 오늘날 조직에서 요구하는 것은
직원들이 원하는 시기에 원하는 방법으로 안전하게 작업할 수 있도록 하는 융통성과 보안입니다. Microsoft® Exchange Server 2007은 Microsoft Office Outlook® Web Access(OWA)와 통합 메시징을 비롯하여, 이러한 요구에 맞는 여러 가지 기능을 기본적으로 제공합니다. Exchange Server 2007의 이 두 가지 주요 구성 요소에 대해 알아보고 이들 구성 요소가 오늘날 기업에서 요구하는 보다 강력한 통신 플랫폼을 만드는 데 있어 이전 버전보다 얼마나 뛰어난지 살펴보겠습니다.
OWA는 버전 5.5부터 Exchange에 포함되었습니다. 솔직히 첫 번째 버전은 다소 부족한 점이 있긴 했지만, 웹 브라우저로 Exchange 사서함에 액세스하는 문제는 해결하였습니다. 하지만 Outlook에서 제공하는 기능을 별로 활용하지 못하였습니다.
Exchange Server 2003과 함께 제공된 개선된 OWA에서는 본격적으로 사용자를 위한 배려가 시작되었으며 마치 클라이언트 프로그램에서 작업하는 것처럼 브라우저 기반 환경에서 훨씬 더 자연스럽게 작업할 수 있었습니다. Exchange Server 2007용 OWA는 여기서 한 단계 더 발전하여, RPC over HTTP나 ASP.NET 2.0 같은 최신 혁신 기술을 활용할 수 있도록 이전 버전을 완전히 새로 작성하였습니다.
예를 들어 OWA의 렌더링 방식을 비교해 보겠습니다. 이전 버전의 OWA에서는 렌더링이 저장 프로세스 과정에서 사서함 서버에 의해 수행되었으므로 사서함 서버의 로드가 증가하여 시스템 성능이 저하될 가능성이 있었습니다. 하지만 Outlook Web Access 2007에서는 CAS(클라이언트 액세스 서버)에서 ASP.NET을 통해 데이터가 렌더링되므로 사서함 서버의 페이지 처리 로드가 줄어들어 성능이 향상되었습니다.
프런트 엔드에서 수행되는 작업도 변경되었습니다. 이전 버전의 Exchange에서는 프록시를 통해 OWA HTTP 요청을 해당 사서함 서버에 보냈지만, Exchange Server 2007에서는 RPC를 통해 해당 사서함 서버에서 데이터를 직접 가져오기 때문에 OWA와 관련된 트래픽이 줄어듭니다. 이는 사용자 기업과 연결되는 VPN(가상 사설망)에 속하지 않은 클라이언트에서 Outlook을 사용하는 프로세스와 거의 동일한 프로세스입니다. 그런 다음 OWA는 사서함 정보를 렌더링합니다. Exchange Server 2007에서도 프록시를 통해 OWA 요청을 보낼 수 있지만, 사서함 서버에 직접 보내지 않고 다른 CAS 서버에 전달합니다.
그림 1에서는 Exchange Server 2007의 OWA 아키텍처를 보여 줍니다.
그림 1 OWA가 Exchange Server 리소스에 액세스하는 방법
그림 1 OWA가 Exchange Server 리소스에 액세스하는 방법 (더 작게 보려면 이미지를 클릭하십시오.)
그림 1 OWA가 Exchange Server 리소스에 액세스하는 방법
그림 1 OWA가 Exchange Server 리소스에 액세스하는 방법 (더 크게 보려면 이미지를 클릭하십시오.)

관리
혁신된 Exchange Server 2007의 아키텍처에는 확장된 OWA 관리 옵션이 포함되어 있습니다. Exchange 관리 콘솔이나 Exchange 관리 셸을 사용할 수 있으며, 구성 설정이 여러 곳에 저장됩니다.
Exchange 관리 콘솔을 사용하면 가능한 구성 설정 대부분에 액세스할 수 있습니다. 이를 통해 조각화, 첨부 파일 차단 및 인증 기능을 사용 또는 사용하지 않도록 설정하고, 일정, 작업 목록 및 맞춤법 검사 같은 기능에 액세스하는 등의 작업을 수행할 수 있습니다. Exchange 관리 콘솔에서 수행할 수 있는 모든 작업은 Exchange 관리 셸 작업으로도 수행할 수 있습니다.
또한 Exchange 관리 셸을 사용하여 OWA의 가상 디렉터리를 새로 만들거나 삭제할 수 있습니다. 특히 사용자별 조각화 설정을 보다 정교하게 제어하고 기본 언어 설정을 변경할 수도 있습니다.
Windows 레지스트리는 양식 기반 인증의 시간 제한을 위한 기본 저장소입니다. 이러한 설정은 Exchange 관리 콘솔이나 Exchange 관리 셸을 통해서는 사용할 수 없습니다. Active Directory®를 통해서만 첨부 파일 차단이나 조각화 같은 OWA 설정에 액세스할 수 있습니다. IIS 메타베이스에는 IIS 동작에 영향을 미치는 설정(인증, GZIP)이 포함되고 web.config에는 OWA 첨부 파일의 업로드를 제어하는 "maxuploadsize" 같은 ASP.NET 설정이 저장됩니다.

인증
OWA는 서버에서 선택할 수 있는 여러 가지 인증을 제공합니다. 설치 후 보안은 기본적으로 양식 기반 인증으로 설정되지만 조직의 요구 사항에 맞춰 필요한 경우 여러 가지 방법으로 보안을 강화할 수 있습니다. IIS는 들어오는 사용자에게 일치하는 도메인 권한이 있는지 확인하기 위해 Active Directory와 비교하여 인증을 수행합니다. 기본 인증, 다이제스트 인증, RSA SecurID 또는 스마트 카드 로그인을 사용하여 전자 메일에 액세스할 수도 있습니다.
OWA에 대한 가장 강력한 수준의 보안은 Kerberos와 NTLM을 결합한 Windows 통합입니다. 실제로 Windows 통합은 Active Directory 사이트 간의 CAS 프록시뿐 아니라 Outlook Web Access 2007 웹 파트 액세스에도 필요합니다. 또한 인트라넷에서 OWA에 액세스하는 사용자에게는 추가적인 이점도 제공합니다. 즉, Windows 클라이언트 인증을 사용한 Single-Sign-On을 제공하므로 이미 트러스트된 사용자인 경우 OWA에 로그온하지 않아도 됩니다.
기본값인 양식 기반 인증을 사용하는 경우 OWA는 비활성 기간이 지나면 자동으로 시간 초과됩니다. 로그인할 때 표시되는 창에서 사용자가 공용 컴퓨터를 선택했는지 아니면 개인 컴퓨터를 선택했는지에 따라 제한 시간은 15분(공용 컴퓨터의 경우)이 될 수도 있고 8시간(개인 컴퓨터의 경우)이 될 수도 있습니다. 공용 컴퓨터 또는 개인 컴퓨터를 선택함에 따라 여타 보안 설정이 다르게 구성될 수 있기 때문에 이 선택은 사용자에게 중요합니다. 예를 들어 공용 컴퓨터에서는 첨부 파일을 차단하거나, 인증 제한 시간을 변경할 수 있습니다. 양식 기반 인증은 그림 2와 같이 기본적으로 4단계의 프로세스입니다.
그림 2 인증 프로세스
  1. 클라이언트는 암호화되지 않은 요청을 서버에 보냅니다.
  2. 서버는 암호화된 쿠키를 다시 클라이언트에 보냅니다.
  3. 서버는 메모리에 세 개의 최신 키를 유지하면서 새 암호화 키 삭제와 만들기를 계속합니다.
  4. 여전히 메모리에 남아 있는 오래된 암호화 키로 요청을 보내는 클라이언트는 최신 키로 암호화된 새 쿠키를 받습니다.
    £또는£
    삭제되었거나 시간 초과된 오래된 암호화 키를 사용하여 요청을 보내는 클라이언트는 다시 로그온해야 합니다.

msExchQueryBaseDN은 특정 사용자가 OWA 주소록의 하위 섹션만을 보도록 제한하는 데 사용되는 메커니즘입니다. MsExchQueryBaseDN은 Active Directory 사용자 개체에 찍히고 AL(주소 목록)이나 OU(조직 단위)를 가리킵니다. 이 AL은 사용자의 GAL(전체 주소 목록)로 사용되고 사용자는 이 OU에서 사용자 계정만이 포함된 GAL을 보게 됩니다. LDAP를 사용하여 msExchQueryBaseDN을 설정할 수 있습니다.

이전 버전과의 호환성
Exchange Server 2007이 제공하는 Outlook Web Access의 핵심은 CAS입니다. CAS 모델은 이전 버전의 Exchange를 실행 중인 서버에 최대한의 상호 운용성을 제공하기 위해 만들어졌습니다. 이 기능이 제대로 작동하려면 항상 CAS 서버를 배포하거나 업그레이드한 후에 연결된 사서함 서버를 업그레이드해야 합니다.
CAS 역할을 하는 Exchange 2007 서버를 사용하여 Exchange 2000 및 Exchange 2003 서버의 사서함에 연결할 수 있습니다. 부분 사이트 업그레이드를 수행하면 RPC over HTTP와 Exchange ActiveSync® 모두 계속해서 작동합니다. /exchange, /public 또는 /exchweb 가상 디렉터리를 통해 액세스하면 OWA와 WebDAV도 역시 작동합니다. 또한 Exchange Server 2007에서 이러한 이전 버전에 대해 사용자 지정 OWA 가상 디렉터리를 만들 수 있습니다.

아주 유용한 ISA Server 2006
Outlook Web Access는 Exchange Server 2007에서 더욱 발전했지만 ISA(Internet Security and Acceleration) Server 2006과의 결합을 통해 훨씬 더 개선될 수 있습니다.있습니다.
ISA Server 2006은 통합 에지 보안 게이트웨이로서, 인터넷에서 발생하는 위험 요소로부터 사이트를 보호하도록 지원할 뿐 아니라 응용 프로그램과 데이터에 대한 보안 원격 액세스도 제공합니다. 이는 OWA의 목표이기도 하므로 OWA와 ISA Server를 결합하면 모든 컴퓨팅 개념 중에서 가장 멋진 개념인 시너지 효과를 얻을 수 있습니다. ISA Server에 대한 자세한 정보는 www.microsoft.com/korea/isaserver/evaluation/default.mspx를 참조하십시오.
ISA Server 2006은 문제를 겪고 있는 Exchange 관리자에게 여러 가지 이점을 제공합니다. 예를 들어 WPLB(웹 게시 부하 분산) 기능을 사용하면 HTTP 쿠키를 통해 부하를 분산시킬 수 있습니다. 심지어 클라이언트 IP가 변경된 경우에도 클라이언트-서버 선호도를 보장할 수 있습니다. ISA Server 2006에서 제공하는 GZIP 압축 및 압축 풀기 기능을 사용하여 웹 서버에서 압축 부하를 줄이거나 트래픽을 분석할 수 있습니다. ISA Server 2004에서는 OWA와 함께 HTTP 압축을 사용할지 또는 ISA Server와 함께 양식 기반 인증을 사용할지 선택해야 했습니다. 다행히 ISA Server 2006에서는 둘 다 동시에 지원합니다.
또한 ISA Server를 통해 OWA 링크 변환을 수행할 수 있습니다. 인트라넷 링크가 OWA 전자 메일에 삽입된 경우 ISA Server가 이 링크를 적절한 인터넷 링크로 변환할 수 있습니다. 이 기능은 상당히 유용하긴 하지만, OWA를 게시하고 있는 ISA 배열과 동일한 배열에 인트라넷 링크를 게시해야 한다는 것을 기억해야 합니다.
ISA Server 2006과 관련하여 가장 중요한 사실은 아마도 이 서버가 경계에서 네트워크를 보호하기 위해 사전 인증을 수행한다는 점일 것입니다. 사전 인증의 목적은 악의적인 HTTP 트래픽이 서버에 접근하지 못하도록 하는 것입니다. CAS로 들어가고 있는 트래픽이 실제로 유효한 트래픽이면 ISA Server는 경계에서 도메인으로 해당 트래픽을 보냅니다. 경계 서버는 인트라넷 도메인 외부에서 해당 도메인에 속하지 않는 트래픽을 차단합니다. CAS는 경계 도메인에 배포해선 안 되며, Active Directory 사용자 계정에 액세스할 수 있도록 인트라넷 도메인에 있어야 합니다.

Outlook Web Access 문제 해결
Outlook Web Access 2007에는 모니터링과 문제 해결을 개선하는 새로운 도구가 포함되어 있습니다. CAS 서버에서는 모니터링 작업이 자동으로 실행되어 각 사서함 서버의 연결과 OWA 로그온을 테스트합니다. Exchange Server 2007에서는 훨씬 더 자세한 이벤트 로그 메시지와 성능 카운터도 제공합니다.
OWA가 올바르게 구성되지 않은 경우 관리자에게 관련 경고와 오류를 표시하도록 Exchange Server Best Practices Analyzer(www.microsoft.com/technet/technetmag/issues/2006/01/TuneUpExchange(영문) 참조)가 개선되었습니다. LogParser 도구를 통해 IIS 로그에서 OWA 사용량 보고서를 만들 수도 있습니다(2006년 10월 기사(www.microsoft.com/technet/technetmag/issues/2006/10/LogParser)(영문) 참조).

통합 메시징
OWA는 모바일 비즈니스에 대한 요구를 해결하는 반면, 통합 메시징은 여러 가지 형태의 메시징을 단일 장소로 통합합니다(여기서 “통합” 메시징이라는 이름이 유래함). 이제 전자 메일은 Exchange Server에서 실시간으로 사용할 수 있고 음성(전화, 음성 메일)은 전화 통신 서버에서 사용할 수 있습니다. 데스크톱에서 전자 메일을 받고 전화를 통해 음성 메일을 확인하고 심지어 팩스 메시지 작성을 시작할 수도 있습니다!
Exchange Server 2007 통합 메시징을 사용하면 조직에서는 전자 메일, 음성 및 팩스 데이터를 하나의 받은 편지함으로 배달할 수 있으므로 사용자는 Outlook과 OWA를 통해 이 모든 데이터에 액세스할 수 있습니다. 통합 메시징은 다른 방향으로도 가능하므로 사용자는 Outlook Voice Access에서 전화를 통해 음성 메일, 전자 메일, 연락처 및 일정에 액세스할 수 있습니다.
통합 메시징은 Exchange 인프라와 전화 통신 인프라를 결합하여 메시징을 단순화하기 때문에 이는 시스템 관리자에게 하나의 저장소 솔루션, 하나의 디렉터리 및 하나의 전송을 의미합니다. 또한 각 사용자가 단일 사서함을 가진다면 전체적으로 더 단순해집니다.
이 중에서도 가장 뛰어난 점은 무엇일까요? 이는 기존 서버로도 수행할 수 있는 작업인데, Exchange Server 2007과 전화 통신을 알고 있다면 더욱 쉽게 배울 수 있습니다. 바로 통합 메시징의 기능이 Exchange와 통합되었다는 점입니다. 이제 동일한 보안 모델과 동일한 받은 편지함을 사용하게 됩니다. 심지어 OWA를 통해 음성 메일과 팩스에도 액세스할 수 있습니다.
그림 3에서는 통합 메시징 서버 역할이 설치된 Exchange Server 2007의 통합 메시징 아키텍처를 보여 줍니다. 이 아키텍처를 잘 살펴본 다음(나중에 퀴즈가 있을 수 있음) 통합 메시징 아키텍처를 더 자세히 살펴보겠습니다.
그림 3 음성, 팩스 및 전자 메일 통신을 결합하는 통합 메시징
그림 3 음성, 팩스 및 전자 메일 통신을 결합하는 통합 메시징 (더 작게 보려면 이미지를 클릭하십시오.)
그림 3 음성, 팩스 및 전자 메일 통신을 결합하는 통합 메시징
그림 3 음성, 팩스 및 전자 메일 통신을 결합하는 통합 메시징 (더 크게 보려면 이미지를 클릭하십시오.)
기업에서 통합 메시징을 설정할 경우 많은 요소를 인지하고 있어야 합니다. Exchange Server에는 전화 통신 하드웨어를 나타내는 개체가 포함되어 있는데, 나중에 Exchange Server 환경 내에서 이러한 개체의 관계를 정의할 수 있습니다. Exchange Server 통합 메시징 시스템 개체로는 UM 서버, UM 다이얼 플랜, UM IP 게이트웨이, UM 헌트 그룹, UM 사서함 정책, UM 자동 전화 교환 등이 있습니다. 이러한 각각의 개체가 필요한 이유는 무엇인지 잠깐 살펴보겠습니다.
UM 서버 개체는 UM 서버 역할이 설치된 Active Directory에 생성되는데, 관리자는 이를 사용하여 Exchange Server 2007 통합 메시징 배포의 설정 및 속성을 제어할 수 있습니다. UM 다이얼 플랜은 통합 메시징 내의 기본 관리 단위로, 내선이 내부적으로 사용되는 방법을 나타냅니다. 다이얼 플랜 내의 모든 사용자는 내선 번호를 누르기만 하면 다른 모든 사용자와 연결할 수 있습니다. 다른 위치를 함께 묶을 경우 일반적으로 위치별로 자체 다이얼 플랜을 갖게 됩니다.
UM IP 게이트웨이 개체는 실제 VoIP(Voice over Internet Protocol) 게이트웨이 또는 SIP(Session Initiation Protocol) 가능 IP PBX(Private Branch Exchange)를 나타냅니다. 통합 메시징 서버는 IP/VoIP 게이트웨이 장치로부터 통화를 수신할 수 있습니다. UM 헌트 그룹은 IP 게이트웨이를 UM 다이얼 플랜과 연결합니다. PBX에서 헌트 그룹이 구성된 후 Active Directory에 이를 나타내는 UM 헌트 그룹이 생성됩니다. IP 게이트웨이를 통해 부하를 분산하도록 헌트 그룹을 구성할 수 있습니다. 그러면 이들 게이트웨이는 단일 UM 헌트 그룹을 여러 게이트웨이에 연결하여 부하를 분산시킵니다. UM 사서함 정책은 음성 메일 서비스 클래스와 유사하며, 사용자 및 그룹의 운영 정책을 설정하는 속성과 다이얼 플랜을 포함합니다.
UM 자동 전화 교환은 단일 UM 다이얼 플랜과 연결할 수 있으며, 여러 날짜와 시간에 대한 사용자 지정 프롬프트 기록 및 정의 작업 등의 여러 가지 작업을 수행하도록 사용자 지정할 수 있습니다. 주소 목록을 사용하여 자동 전화 교환의 범위를 지정할 수 있습니다.
그림 4에서는 이러한 6개의 통합 메시징 개체가 서로 도와 가면서 어떻게 작업하는지 보여 줍니다.
그림 4 통합 메시징 전화 통신 개체의 상호 작용
그림 4 통합 메시징 전화 통신 개체의 상호 작용 (더 작게 보려면 이미지를 클릭하십시오.)
그림 4 통합 메시징 전화 통신 개체의 상호 작용
그림 4 통합 메시징 전화 통신 개체의 상호 작용 (더 크게 보려면 이미지를 클릭하십시오.)

설정
사용자가 일단 Exchange Server 2007 사서함을 소유하게 되면 관리자는 통합 메시징을 위해 해당 사서함을 활성화해야 합니다. 이렇게 하려면 관리자가 다이얼 플랜 내에서 UM 사서함 정책 및 내선 번호에 사서함을 연결해야 합니다. RNA(Ring, No Answer) 시 통화를 통합 메시징으로 라우팅하도록 PBX도 구성해야 합니다. PBX는 먼저 통화를 사용자의 내선 번호로 라우팅합니다. 그런 다음 RNA가 발생하면 통화가 VoIP 게이트웨이로 라우팅되고 다시 통합 메시징 서버로 라우팅됩니다.
통합 메시징은 확장 가능합니다. 필요한 용량에 따라 개수에 상관없이 회선 교환 PBX 채널과 UM 서버를 추가할 수 있습니다. VoIP 게이트웨이를 사용하면 IP 기반 통화가 Exchange 통합 메시징에 배달됩니다. 이는 대부분의 기업에서 새로운 기능이므로 전체 네트워크 분석을 통해 IP 네트워크의 대역폭이 데이터와 음성을 모두 처리할 수 있을 만큼 충분한지 확인해야 합니다.
일반적인 Exchange Server 2007 통합 메시징 서버는 50~200개의 동시 IP 통화와 최대 200개의 들어오는 음성 및 팩스 통화(기본적으로 100개로 설정되어 있음)를 처리할 수 있습니다. 이보다 더 큰 용량이 필요하거나 내결함성을 높이려는 경우 통합 메시징 서버를 추가로 구축할 수 있습니다.

요약
원하던 기능이 드디어 구현되었습니다! Exchange Server 2007의 두 가지 기능인 Outlook Web Access와 통합 메시징을 함께 사용할 경우 조직에서 얻을 수 있는 이점은 엄청납니다. Outlook Web Access를 사용하면 어디서나 전자 메일에 안전하게 액세스할 수 있으며, 통합 메시징을 사용하면 사용자가 Exchange 2007 사서함을 벗어날 필요 없이 이 사서함 내에서 자신의 모든 전자 메일, 음성 메일, 팩스 메시지 및 기타 사서함 데이터에 액세스할 수 있습니다.

Joshua Trupin은 MSDN Magazine과 TechNet Magazine의 편집장으로, 많은 MSJ, MIND, MSDN Magazine 및 TechNet Magazine 기사를 집필하였으며 Hoop Stats: The Basketball Abstract라는 책도 저술하였습니다.


 Exchange Server 2007: Exchange 2007의 더욱 강력해진 저널링
Exchange Server 2007 David Strome

Exchange 2007의 더욱 강력해진 저널링
한 눈에 보기:
  • Exchange Server 2007 저널 규칙
  • 새 저널 마법사
  • 저널 보고서의 내용

특정 사용자에게 보내거나 특정 사용자로부터 받은 전자 메일 메시지를 저널링해야 했는데 결국 찾고 있던 메시지와 함께
해당 사서함 저장소에 있는 다른 사서함 300개에 있는 메시지를 모두 저널링한 적이 있습니까? Microsoft Exchange Server 2007에서는 이 문제를 해결하여 사용자가 필요한 대로 정교하게 제어할 수 있습니다.
엔터프라이즈 CAL(클라이언트 액세스 라이선스)과 함께 사용할 수 있는 받는 사람 단위 저널링을 통해 저널링할 대상을 지정할 수 있습니다. 저널 규칙을 사용하여 이제 원하는 받는 사람과 보낸 사람만을 저널링할 대상으로 지정할 수 있습니다. 저널링 대상을 단일 사서함으로 좁히거나 모든 영업부 직원을 포함하도록 넓힐 수 있으며 해당 사서함이 같은 서버, Active Directory® 사이트 또는 Exchange 조직에 있지 않아도 됩니다. Active Directory 복제를 통해 조직에서 Hub 전송 서버 역할을 실행 중인 모든 컴퓨터에 변경 내용을 자동으로 적용할 수도 있습니다.

저널링 작동 방식
Exchange Server 2003에서는 저널링이 각 실제 서버의 개별 사서함 저장소 단위로 구현되었습니다. 조직의 모든 사서함을 저널링하려는 경우 각 사서함 저장소에서 저널링을 구성해야 했으며 특정 받는 사람에 대한 메시지를 저널링하려는 경우 해당 사용자의 사서함 저장소에 있는 모든 사람을 저널링하거나 해당 사용자 전용의 새 사서함 저장소를 만들어야 했습니다.
Exchange Server 2007에서는 저널링이 Exchange의 새로운 역할 기반 토폴로지를 이용합니다. 그림 1과 같이 모든 메시지는 사서함 및 통합 메시징 서버, 다른 Exchange 시스템, 타사 응용 프로그램, 인터넷 등을 통해 나가거나 들어올 때 Hub 전송 서버에서 처리됩니다. 모든 Hub 전송 서버에는 메시지에 대한 저널 규칙 적용을 담당하는 저널링 에이전트라는 전송 에이전트가 있습니다. 저널링 에이전트는 Hub 전송 서버에 있으므로 메시지가 받는 사람에게 도달하기 전에 모든 메시지와 접하게 되므로 모든 메시지를 평가합니다. 저널링 에이전트는 분류 작업을 마친 메시지에 작용하므로 모든 메시지의 받는 사람과 보낸 사람 특성에 대한 액세스가 보장되고 메시지가 받는 사람에게 직접 전송되었는지 또는 메일 그룹 확장을 통해 수신되었는지 판별할 수 있습니다. 받는 사람이 Exchange Server 2007 조직 내에서 작성된 메시지의 받는 사람, 참조 또는 숨은 참조 항목에 있었는지 여부도 알 수 있습니다.
그림 1 Hub 전송 서버 메일 흐름
그림 1 Hub 전송 서버 메일 흐름 (더 작게 보려면 이미지를 클릭하십시오.)
그림 1 Hub 전송 서버 메일 흐름
그림 1 Hub 전송 서버 메일 흐름 (더 크게 보려면 이미지를 클릭하십시오.)
저널링 에이전트는 메시지가 Hub 전송 서버를 통과할 때 메시지에 관리자가 구성한 저널 규칙을 적용합니다. 이러한 규칙을 통해 저널링 에이전트가 메시지에 대한 정보를 캡처하여 원본 메시지와 함께 이 정보를 저널 사서함에 전달할지 여부가 결정됩니다. 이 데이터는 저널 보고서라는 메시지에 포함되어 전송됩니다.
이전 Exchange 버전에서는 여러 서버에 구성을 적용해야 했습니다. 그러나 Exchange Server 2007에서는 저널 규칙을 작성할 때 Active Directory를 통해 조직의 모든 Hub 전송 서버에 해당 변경 내용이 적용됩니다. 이로 인해 모든 Hub 전송 서버와 모든 저널링 에이전트는 Active Directory에서 같은 구성을 읽습니다. 따라서 모든 저널링 에이전트가 같은 저널링 구성을 적용합니다.
조직 전반에 걸쳐 구성 변경 내용을 복제하고 Hub 전송 서버에서 구성 변경 내용을 읽어야 하므로 저널 규칙을 작성하거나 수정할 때는 Active Directory 복제 시간을 염두에 두어야 합니다. 이 작업은 몇 시간 정도 걸릴 수 있습니다. 저널링 구성의 업데이트 시기를 쉽게 확인할 수 있도록 각 서버의 보안 이벤트 로그에 이벤트가 기록됩니다.
Exchange Server 2007에서는 저널 사서함이 용량 초과, 잘못된 구성, 오프라인 상태 등으로 인해 사용하지 못하는 경우 저널 보고서가 결코 손실되지 않는데, 이는 특히 메시지 손실로 인해 요구 사항이 준수되지 않는 상황이 발생할 수 있는 다양한 법률 및 규정 요구 사항을 준수해야 하는 경우에 유용합니다. 저널 보고서가 저널 사서함에 전달될 수 없으면 저널 사서함을 사용할 수 있게 될 때까지 Hub 전송 서버의 큐에 보고서가 남아 있습니다. 따라서 큐가 급격하게 커질 수 있으므로 저널 사서함의 가용성을 모니터링하여 올바르게 작동하고 있는지 확인해야 합니다. 저널 사서함을 오랫동안 사용할 수 없는 경우 큐에 있는 보고서를 받을 대체 방안을 구성할 수 있습니다.

저널링할 대상 결정
저널 규칙을 작성하기 전에 저널링할 대상과 데이터 형식을 분명하게 결정해야 합니다. 저널 규칙에 사용자를 지정하여 특정 사용자를 저널링 대상으로 선택할 수 있습니다. 예를 들어 이러한 사용자는 규정 요구 사항을 준수해야 하거나 전자 메일 메시지나 다른 통신 내용을 증거로 수집해야 하는 법률 소송과 관련이 있을 수 있습니다.
저널링할 받는 사람을 지정하는 것 외에도 내부, 외부 및 글로벌 옵션으로 저널링할 메시지 범위를 결정할 수 있습니다. 내부는 조직 내의 메시지만을 대상으로 하고 외부는 보낸 사람이나 받는 사람 중 하나가 외부에 있는 메시지를 대상으로 하며 글로벌은 내부 메시지와 외부 메시지를 모두 대상으로 합니다. 글로벌 옵션은 내부 범위와 외부 범위를 사용하는 규칙으로 이미 처리되었을 수 있는 메시지를 포함하여 Hub 전송 서버를 통과하는 메시지를 모두 저널링합니다.
Exchange Server 2007에서는 통합 메시징을 지원하므로 사용자의 받은 편지함에서 해당 사용자의 전자 메일, 음성 메일 및 팩스를 모두 수집하도록 Exchange를 구성할 수 있습니다. 이렇게 하면 이 모든 데이터를 저널링할 수 있으며 원하지 않는 경우 특정 데이터를 제외하도록 선택할 수도 있습니다.
표준 CAL을 사용하여 Exchange Server 2007을 실행 중인 경우 여전히 사서함 저장소 단위 저널링을 사용할 수 있습니다. 그러나 새 받는 사람 단위 저널링 기능을 사용하려면 Exchange Server 2007 엔터프라이즈 CAL로 업그레이드해야 합니다.

저널 사서함 저장 위치
저널링할 대상을 결정했으면 저널 보고서를 보낼 위치를 결정해야 합니다. 여러 사이트가 있으면 저널 사서함을 저장할 위치를 결정할 때 현재 네트워크 토폴로지나 계획된 네트워크 토폴로지를 고려해야 합니다. 조직 크기와 사서함 수에 따라 저널링이 상당수의 같은 보고서를 반복해서 작성할 수 있습니다.
굳이 Exchange 사서함만 고집할 필요는 없습니다. 저널 보고서는 모든 유효한 SMTP 주소에 보낼 수 있습니다. 이 주소는 Exchange Hosted Services, 타사 보관 솔루션, 메일 그룹을 사용하는 이러한 서비스나 솔루션의 조합 등을 가리킬 수 있습니다. 그러나 저널 보고서를 보내는 위치와 관련하여 알아야 할 특정 보안 사항이 있습니다.
저널 사서함을 저장할 위치에 관계없이 Active Directory에서 해당 위치에 대한 받는 사람 개체를 만들어야 합니다. 이 개체는 Exchange Server 2007 사서함, 메일을 Exchange Hosted Services나 타사 보관 솔루션으로 리디렉션하는 메일 사용 가능 연락처, 사서함과 연락처를 모두 포함하는 메일 그룹 등이 될 수 있습니다.

저널 보고서의 내용
메시지를 저널링할 때 저널링 에이전트는 저널 보고서에서 원본 메시지에 대한 정보를 최대한 자세히 캡처하려고 합니다. 그런 다음 이 보고서가 저널 사서함에 전송됩니다. 이 정보는 메시지의 의도, 받는 사람 및 보낸 사람을 확인할 때 매우 중요합니다. 예를 들어 받는 사람이 식별된 위치(해당 주소가 받는 사람 필드에 직접 지정되어 있는지, 참조 필드에 포함되어 있는지, 그냥 메일 그룹에 속해 있는지 여부)는 받는 사람이 해당 메시지의 내용과 어떠한 관련이 있는지 확인하는 데 도움이 될 수 있습니다. 원본 메시지는 첨부 파일로 포함됩니다. 그림 2의 스크린 샷은 david@contoso.com에 보낸 메시지가 christine@contoso.com에 전달되었음을 나타내는 저널 보고서와 Sales_Group@contoso.com 메일 그룹에 보낸 메시지가 확장되었고 "Sales Group"(영업 그룹) 메일 그룹에 속한 받는 사람 lukas@contoso.com이 해당 메시지를 받았음을 나타내는 저널 보고서를 보여 줍니다. 두 보고서 모두 원본 메시지가 첨부 파일로 포함되어 있으며 원래 보낸 사람이 brian@contoso.com이고 제목이 "Sales forecast"(판매 예측)임을 보여 줍니다.
그림 2 전달된 받는 사람과 확장된 메일 그룹 받는 사람을 보여 주는 저널 보고서
그림 2 전달된 받는 사람과 확장된 메일 그룹 받는 사람을 보여 주는 저널 보고서 (더 작게 보려면 이미지를 클릭하십시오.)
그림 2 전달된 받는 사람과 확장된 메일 그룹 받는 사람을 보여 주는 저널 보고서
그림 2 전달된 받는 사람과 확장된 메일 그룹 받는 사람을 보여 주는 저널 보고서 (더 크게 보려면 이미지를 클릭하십시오.)
Exchange에서는 올바르다고 알려진 정보만 분류합니다. 자동으로 확인할 수 없는 정보는 저널 보고서의 해당 필드에 입력됩니다. 그림 2에서는 저널 보고서 본문에 포함된 필드를 설명합니다.

보안에 대한 모든 것
기본적으로 같은 Exchange 조직에서 Exchange Server 2007을 실행 중인 컴퓨터 간의 모든 통신은 암호화됩니다. 이러한 암호화는 저널 보고서에 대해서도 수행됩니다. Exchange Server에서는 다음과 같이 저널 보고서가 훼손될 위험을 줄이는 데 도움이 되는 여러 작업이 수행됩니다.
  • Exchange 2007 조직의 Hub 전송 서버와 사서함 서버 간에 보안 연결이 사용됩니다.
  • 원본 메시지를 보낸 사람 대신 "Microsoft Exchange"로 저널 보고서가 전송됩니다.
  • Hub 전송 서버와 사서함 서버 간의 세션이 인증됩니다.
  • 같은 Exchange 2007 조직의 Hub 전송 서버와 사서함 서버 간에 저널 보고서를 보낼 때 인증된 연결만 받아들여집니다.
저널 사서함을 만들 때는 사서함에 조직 내의 받는 사람이 보내거나 받는 메시지가 포함되므로 해당 사서함을 안전하게 보호해야 합니다. 일부 메시지가 법률 소송에 사용되거나 규정 요구 사항을 준수해야 할 수 있으며 조사 당국에 제출하기 전에 메시지를 훼손되지 않은 상태로 유지할 것을 요구하는 여러 법률이 있을 수 있습니다. 저널 사서함 보안을 강화하려면 Microsoft Exchange 보낸 사람의 메시지만을 받아들이도록 저널 사서함을 구성해야 하고 저널 사서함에 전송되는 모든 메시지를 인증된 보낸 사람이 보내도록 요구해야 합니다. 그림 3에서는 저널 사서함에 구성된 메시지 배달 제한을 보여 줍니다. 다음 Exchange 관리 셸 명령을 사용하여 이러한 메시지 배달 제한을 구성할 수도 있습니다.
Set-Mailbox <Journal Mailbox Name>
-AcceptMessagesOnlyFrom "Microsoft Exchange" -RequireSenderAuthenticationEnabled $True
그림 3 메시지 배달 제한 사항
그림 3 메시지 배달 제한 사항 (더 작게 보려면 이미지를 클릭하십시오.)
그림 3 메시지 배달 제한 사항
그림 3 메시지 배달 제한 사항 (더 크게 보려면 이미지를 클릭하십시오.)
저널 보고서를 Exchange Server 2007 조직 외부에 있는 저널 사서함에 보내는 경우에는 Exchange Server 2007 컴퓨터와 받는 서버 간의 연결을 수동으로 암호화하고 안전하게 보호해야 합니다. 이러한 작업은 두 시스템 간에 TLS(전송 계층 보안)를 사용할 것을 요구하고, 받는 시스템에서 인증을 요구하며, 받는 시스템에서 Microsoft Exchange 받는 사람의 SMTP 주소(이 SMTP 주소는 Exchange_UMUnique GUID@contoso.com과 비슷함)에서 보낸 메시지만을 받아들이고, Microsoft Exchange 받는 사람이 보낸 메시지만 받아들이도록 메시지를 전달하는 데 사용되는 Active Directory 연락처를 구성하여 수행할 수 있습니다.

저널 규칙 구현
이미 충분히 설명했으므로 이제 몇 가지 규칙을 구현해 보겠습니다. 저널링 에이전트의 저널 규칙은 Exchange 관리 셸이나 Exchange 관리 콘솔에서 구성할 수 있습니다. 이 둘 모두 받는 사람, 범위 및 저널 사서함 설정을 구성하는 데 사용할 수 있습니다. 기본적으로 저널 규칙은 작성할 때 사용하도록 설정됩니다. 저널 전자 메일 주소로 지정하는 값은 Exchange Server 2007 조직에 이미 있는 받는 사람 개체여야 합니다. 이 받는 사람 개체는 사서함, 메일 그룹, 동적 메일 그룹, 메일을 SMTP 주소로 보내는 연락처 등이 될 수 있습니다.
Exchange 관리 콘솔에서는 새 저널 규칙 마법사가 새 저널 규칙을 작성하는 과정을 단계별로 안내합니다. 조직 구성 섹션에서 Hub 전송 서버 역할을 선택한 다음 동작 창에서 새 저널 규칙을 클릭합니다. 여기에서 규칙 이름, 저널 전자 메일 주소 및 범위의 값을 지정해야 합니다. 저널 규칙에서 조직의 모든 받는 사람에 대한 메시지를 저널링하도록 설정하려는 경우에는 받는 사람 필드의 값을 지정하지 않아도 됩니다. 저널 규칙을 작성할 때 사용하지 않도록 설정할지 여부를 선택할 수도 있습니다. 그림 4에서는 brian@contoso.com이 보내거나 받는 메시지를 모두 저널링하는 샘플 구성을 보여 줍니다. 저널링된 메시지는 Compliance Mailbox라는 저널 사서함에 전송됩니다.
그림 4 새 저널 규칙 마법사
그림 4 새 저널 규칙 마법사 (더 작게 보려면 이미지를 클릭하십시오.)
그림 4 새 저널 규칙 마법사
그림 4 새 저널 규칙 마법사 (더 크게 보려면 이미지를 클릭하십시오.)
Exchange 관리 셸에서는 다음 6개의 cmdlet를 사용하여 저널링 에이전트를 관리할 수 있습니다.
  • New-JournalRule
  • Set-JournalRule
  • Get-JournalRule
  • Remove-JournalRule
  • Enable-JournalRule
  • Disable-JournalRule
New-JournalRule cmdlet를 사용하여 새 저널 규칙을 작성할 수 있습니다. 이 방식으로 새 저널 규칙을 작성하기 위한 기본 조건은 마법사를 사용할 때와 같습니다. Name, Scope 및 JournalEmailAddress 매개 변수의 값을 지정해야 합니다. 또한 저널 규칙에서 조직의 모든 받는 사람에 대한 메시지를 저널링하도록 설정하려는 경우에는 Recipient 매개 변수의 값을 지정하지 않아도 됩니다. 그리고 저널 규칙을 작성할 때 사용하지 않도록 설정하려면 Enabled 매개 변수의 값으로 $False를 지정해야 합니다. 그림 4에 표시된 것과 같은 구성을 가진 저널 규칙을 작성하려면 다음 명령을 사용합니다.
New-JournalRule
-Name "Brian Smith Journal Rule"
-Recipient brian@contoso.com
-JournalEmailAddress "Compliance Mailbox"
-Scope Global
Get-JournalRule cmdlet를 사용하여 작성한 모든 저널 규칙의 목록을 볼 수 있습니다. 이 cmdlet를 자체적으로 실행하면 조직에 구성된 저널 규칙 모두의 요약 목록과 해당 구성 설정이 표시됩니다. 저널 규칙에 대한 정보를 모두 보려면 Get-JournalRule cmdlet를 Format-List cmdlet에 파이프하면 됩니다. 파이핑이 한 cmdlet의 출력을 다음 cmdlet에 보내므로 두 번째 cmdlet에서 해당 출력에 대한 추가 처리를 수행할 수 있습니다. 예를 들어 Format-List cmdlet는 받은 출력을 모두 표시합니다. 이전에 작성한 저널 규칙에 대한 정보를 모두 보려면 다음 명령을 사용할 수 있습니다.
Get-JournalRule -Identity "Brian Smith Journal Rule" | Format-List
저널 규칙을 사용하도록 설정하려면 Enable-JournalRule cmdlet를, 사용하지 않도록 설정하려면 Disable-JournalRule cmdlet를 사용합니다. 이러한 cmdlet를 사용할 때는 Identity 매개 변수에 저널 규칙 이름을 지정해야 합니다. 예를 들어 방금 작성한 저널 규칙을 사용하지 않도록 설정하려면 다음 명령을 사용합니다.
Disable-JournalRule -Identity "Brian Smith Journal Rule"
Set-JournalRule cmdlet를 사용하면 기존 저널 규칙을 수정할 수 있습니다. 저널 규칙 이름은 Identity 매개 변수와 함께 사용되며 저널링 에이전트에 수정 중인 규칙을 알리는 데 사용됩니다. 그런 다음 Recipient, JournalEmailAddress, Scope 또는 이러한 매개 변수의 조합에 새 값을 지정합니다. 예를 들어 방금 작성한 규칙의 JournalEmailAddress 매개 변수에 저장된 값을 수정하려면 다음 명령을 사용합니다.
Set-JournalRule -Identity "Brian Smith Journal Rule" -JournalEmailAddress "Seattle Users Compliance Mailbox"
마지막으로 Remove-JournalRule cmdlet를 사용하여 기존 저널 규칙을 제거할 수 있습니다. Identity 매개 변수를 사용하여 저널 규칙 이름을 지정합니다. 예제 저널 규칙을 삭제하려면 다음 명령을 사용합니다.
Remove-JournalRule "Brian Smith Journal Rule"
이때 Exchange 관리 셸에서 저널 규칙을 삭제할지 묻는 메시지가 표시됩니다. 마지막 팁으로 거의 모든 cmdlet에서 Identity 매개 변수 레이블을 생략하고 매개 변수 값만 지정할 수 있음을 알려 드립니다.

David Strome은 지난 1년간 Microsoft의 Exchange User Education 그룹에서 테크니컬 라이터로 일해 왔으며 미국 워싱턴 주의 레드먼드에 위치한 Microsoft로 오기 전에 10년 정도를 캐나다 브리티시 컬럼비아 소재의 여러 회사에서 Exchange Server 설치를 설계, 구현 및 관리하면서 지냈습니다. 문의 사항이 있으면 dstrome@microsoft.com으로 연락하시기 바랍니다.


 Exchange Server 2007: 보낸 사람 ID로 스팸 및 피싱 방지
Exchange Server 2007 Craig Spiezle and Alexander Nikolayev

보낸 사람 ID로 스팸 및 피싱 방지
한 눈에 보기:
  • 보낸 사람 ID 기본 사항
  • Exchange Server에서 보낸 사람 ID 구성
  • 인증의 이점

스팸의 위협이 증가함에 따라 많은 식별 및 필터링 기술이 개발되었습니다. 이러한 기술은 효과적으로 활용되기 위해 보낸 사람과 같이 각 전자 메일 메시지에 대해 특정 질문을 묻는 것에
의존합니다. 불행히도 메시지를 보낸 사람에 대한 기본적인 질문에도 대답하는 것이 쉽지 않은 경우가 있습니다. 전자 메일은 대개 보낸 사람이나 보낸 사람을 대신하는 컴퓨터에 대한 인증 없이 인터넷을 통해 전송됩니다. 실제로 손쉽게 다른 사람으로 가장하여 전자 메일 메시지를 보낼 수 있으며 스푸핑된 메시지를 자동으로 감지할 수 있는 방법도 없습니다.
전자 메일을 보내거나 받는 데 사용되는 SMTP(Simple Mail Transfer Protocol)는 전자 메일 메시지의 보낸 사람을 확인하도록 고안되지 않았으므로 이 기술의 허점을 이용하여 원하는 이름과 주소를 보낸 사람으로 삽입할 수 있습니다. 따라서 콘텐츠 필터링 또는 스팸 방지 수단에서 메시지의 보낸 사람이 실제로 해당 메시지를 보냈는지 확인할 때 머리글 정보에만 의존할 수는 없습니다.
전자 메일 인증은 특히 이 허점을 해결합니다. 인증을 사용하면 보내는 전자 메일 시스템과 받는 전자 메일 시스템 모두 메시지를 보냈다고 주장하는 도메인에서 정말로 해당 메시지를 보냈는지 확인합니다. 따라서 조직에서는 정크 메일을 효과적으로 필터링하는 동시에 합법적인 전자 메일은 지정된 받는 사람에게 전달하기가 한결 수월해집니다.
오늘날 사용료 없이 전자 메일을 인증하는 방법에는 SIDF(Sender ID Framework)와 DKIM(DomainKeys Identified Mail)의 두 가지가 있습니다. SIDF는 SPF(Sender Policy Framework)와 Microsoft Caller ID for E-Mail이 합쳐져 생성된 IP(인터넷 프로토콜) 기반 솔루션입니다. 2006년 4월 IETF(Internet Engineering Task Force)에서 RFC 4405-4408을 통해 보낸 사람 ID 사양을 발표했습니다. Microsoft를 포함한 업계와 회사 주주 연합에서는 비즈니스 및 기술 가치, 안정성, 완성도, 배포 용이성, 아웃바운드 또는 인바운드 성능에 미치는 최소 영향, ISP 및 엔터프라이즈 환경에 대한 전자 메일 에코시스템과의 상호 운용성 등을 고려하여 SIDF를 배포할 것을 권장합니다.
DKIM은 Yahoo! DomainKeys와 Cisco Systems Inc.의 IIM(Identified Internet Mail) 사양이 합쳐진 사양입니다. 2006년 1월 IETF는 DKIM 작업 그룹 창설을 승인했으며 사양은 현재 IETF의 검토 과정을 거치고 있습니다.
스팸을 완벽하게 방지하는 솔루션은 없지만 SIDF는 스푸핑된 도메인을 차단하기 위한 업계의 중요한 이니셔티브를 대변합니다. 따라서 SIDF는 스팸과 피싱 공격은 줄이고 온라인을 통한 신뢰와 확실함은 높이는 핵심 구성 요소입니다. 전 세계 조직에서 매우 빠른 속도로 SIDF를 채택하고 있습니다. 오늘날 550만 개가 넘는 회사와 도메인 보유자가 SPF 레코드를 게시하고 있으며 6억 명이 넘는 사용자가 SIDF로 보호되고 있습니다. 현재 전 세계의 일일 전자 메일 볼륨 중 1/3 이상이 이미 인증되어 SIDF를 준수합니다.
AOL, AOTA(Authentication and Online Trust Alliance), Bell Canada, ESPC(E-Mail Senders Provider Coalition), CipherTrust, Cisco Systems, IronPort Systems, MarkMonitor, Port25 Solutions Inc, Sendmail, Symantec, TRUSTe, VeriSign 등 많은 조직과 회사의 수고와 지원이 없었다면 SIDF의 개발과 전 세계적인 채택이 불가능했을 것입니다.

보낸 사람 ID 이해
일부 업계 조사에 따르면 피싱 메일의 95% 이상이 스푸핑된 도메인에서 비롯되고 스푸핑된 보낸 사람 전자 메일 주소를 가집니다. 스팸 방지 처리와 관련해서 SIDF가 큰 차이를 보이는 것이 바로 이 부분입니다. SIDF 자체는 스팸 문제를 해결하지 않지만 스팸과 피싱 공격의 결과를 최소화하는 데 크게 기여합니다. 또한 SIDF는 정크 전자 메일을 보내지 못하게 방지하지는 않지만 SIDF를 통해 정크 전자 메일을 훨씬 쉽게 검색할 수 있습니다. 이 프레임워크는 전자 메일 보낸 사람이 자신의 도메인 이름, 평판 및 브랜드를 보호할 수 있도록 하고 보낸 사람의 평판과 전자 메일 동작을 토대로 필터링할지 여부를 결정할 수 있는 확고한 기준을 제공합니다.
보낸 사람 ID는 모든 전자 메일 메시지에 대해 발송처로 표시된 인터넷 도메인과 실제 발송된 인터넷 도메인이 일치하는지 확인을 시도합니다. 이 작업은 전자 메일을 보내는 서버의 주소를 도메인 소유자가 전자 메일을 보낼 권한이 있는 등록된 서버 목록과 대조하여 확인하는 방식으로 수행됩니다. 확인 작업은 메시지가 사용자의 받은 편지함에 배달되기 전에 ISP(인터넷 서비스 공급자)나 받는 사람의 메일 서버에서 자동으로 수행됩니다.
보낸 사람 ID를 비롯한 인증 메커니즘이 콘텐츠 필터링 시스템을 대신할 수는 없습니다. SIDF와 DKIM은 실제 메시지 콘텐츠를 검사하지 않습니다. 대신 인증에서 메시지를 보냈다고 주장하는 보낸 사람이 해당 메시지를 보냈음을 확인할 수 있는지 여부를 인바운드 메일 시스템에 알립니다. 스팸 및 피싱 메시지는 대부분 표시된 도메인이 아닌 다른 도메인에서 발송되므로 이 방법을 사용하면 이러한 메시지를 자동으로 식별하여 수신 메일 스트림에서 분리할 수 있습니다.
SIDF에서 SPF 레코드는 도메인과 연결된 모든 아웃바운드 메일 서버의 간단한 텍스트 레코드를 해당 IP 주소와 함께 제공합니다. 조직에서 DNS 서버 영역 파일에 SPF 레코드를 게시하면 받는 사람 메일 서버가 해당 레코드를 확인합니다. SPF 레코드 설정은 빠르고 간편하며 무료입니다. Sender ID Framework SPF Record Wizard에서 도메인의 메일 서버를 조사하고 게시할 준비가 된 사용자 지정 레코드를 만드는 프로세스를 단계별로 안내합니다. SPF 레코드 게시에 대한 자세한 내용은 microsoft.com/senderid(영문)를 참조하십시오. 이 마법사는 microsoft.com/senderid/wizard(영문)에서 직접 액세스할 수 있습니다.
받는 SMTP 메일 서버는 DNS에서 도메인의 영역 파일을 핑하여 SPF 레코드의 존재 여부를 검사합니다. SPF 레코드가 있으면 보내는 서버의 IP 주소가 나열된 IP 주소에 있는지 확인합니다. 보내는 서버의 IP 주소가 나열된 IP 주소에 있으면 메시지가 인증된 것으로 확인됩니다. 반면에 보낸 사람의 도메인에 대한 SPF 레코드가 메시지를 보낸 IP 주소와 일치하지 않으면 인증이 실패하여 음수 점수로 표시되고 메시지가 정크 메일 폴더에 잠재적으로 배치됩니다. 그림 1에서는 이러한 프로세스를 보여 줍니다.
그림 1 들어오는 메시지에 대한 SPF 레코드 검사
그림 1 들어오는 메시지에 대한 SPF 레코드 검사 (더 작게 보려면 이미지를 클릭하십시오.)
그림 1 들어오는 메시지에 대한 SPF 레코드 검사
그림 1 들어오는 메시지에 대한 SPF 레코드 검사 (더 크게 보려면 이미지를 클릭하십시오.)
메시지에 태그가 지정되어 있는 경우 SIDF를 사용하여 받는 사람 메일 서버가 이전 동작, 보낸 사람의 평판, 해당 콘텐츠, 필요에 따라 정의할 수 있는 다른 조건 등을 기반으로 메시지를 분석할 수 있습니다. 이 기능은 추가 보호 기능을 제공합니다. 예를 들어 스패머가 비슷한 도메인과 게시된 SPF 레코드를 등록하여 해당 메일의 발송처가 합법적인 보낸 사람인 것처럼 사용자 및 수신 네트워크를 속일 수 있습니다. 이런 식으로 전자 메일 메시지가 인증 검사를 통과하더라도 보낸 사람의 평판이 스패머로 지정되어 있으므로 충분히 메시지를 차단하거나 폐기 또는 삭제할 수 있습니다.

보낸 사람 ID 배포 옵션
SIDF를 통한 아웃바운드 전자 메일 인증은 인프라 변경이나 소프트웨어 업데이트를 필요로 하지 않으며 특정 클라이언트 또는 서버 소프트웨어에만 제한되지도 않습니다. 그러나 인바운드 인증을 통합하여 회사와 직원들을 보호하려는 조직에서는 인바운드 시스템과 MTA(메시지 전송 에이전트)를 업데이트하고 SIDF를 지원하는 소프트웨어나 기기를 배포해야 할 수 있습니다. Microsoft® Exchange Server와 Exchange Hosted Filtering을 포함한 업계 최고의 상용 및 소스 개방형 MTA와 스팸 방지 업체 중 대부분이 통합 솔루션을 제공합니다.
Microsoft에서는 Microsoft Exchange Server 2003 서비스 팩 2(SP2), Exchange Server 2007, Microsoft Exchange Hosted Filtering, Microsoft Windows Live™ Mail, MSN® Hotmail®, Outlook® Express, Office Outlook 메시징 및 공동 작업 클라이언트 등의 모든 메시징 제품에 SIDF를 통합했습니다.
그러나 Microsoft조차도 스팸 공격으로부터 벗어날 수 없습니다. Microsoft에는 일일 평균 약 1,500만 개의 메시지가 들어오는데, 최근 스팸 공격 중에는 해당 양의 2~4배가 목격되었습니다. 이와 같은 환경에서 스팸 방지의 성패는 사용 가능한 기술을 얼마나 세심하게 구현하느냐에 달려 있습니다.
Microsoft는 Exchange Server 2003의 보낸 사람 ID 필터와 Exchange Server 2007의 보낸 사람 ID 에이전트를 기반으로 한 내부 Exchange Server 스팸 방지 솔루션을 실행하고 있습니다. 두 버전의 Exchange Server 모두에서 보낸 사람 ID 상태는 해당 DNS 서버에 있는 보낸 사람 ID 레코드의 평가를 기반으로 합니다. 실제 도메인은 다음 우선 순위에 따라 RFC 2822 메시지 머리글을 검사하여 결정됩니다.
  1. Resent-Sender
  2. Resent-From
  3. Sender
  4. From
보낸 사람의 도메인(또는 전자 메일 시스템이 다른 메일 서버를 대신하여 메일을 합법적으로 전달할 수 있기 때문에 가장 최근에 메시지를 메시징 스트림에 넣는 작업을 담당한 엔터티)은 정의된 순서에 따라 방금 언급한 머리글의 첫 번째 정의를 찾아서 결정됩니다. 이러한 머리글을 찾을 수 없으면 SMTP RFC 2821 MAIL FROM 값이 사용됩니다.

보낸 사람 ID 구성
Exchange Server 2007에서는 Edge 전송 역할이 설치된 서버에서 보낸 사람 ID 에이전트를 사용하도록 설정할 수 있습니다. 보낸 사람 ID 에이전트를 사용하면 받는 커넥터를 통과하는 메시지가 필터링되고 외부 원본에서 들어오는 인증되지 않은 트래픽이 모두 보낸 사람 ID 처리를 거치게 됩니다. Exchange Server 2003에서는 보낸 사람 ID 상태가 EXCH50 Blob의 서버 간에 유지되지만 Exchange Server 2007에서는 메시지 메타데이터에도 추가되었습니다. 최종 목적지에서는 나중의 클라이언트가 사용할 수 있도록 둘 다 MAPI 속성으로 변환됩니다.
Exchange Server 2003의 메시지 배달 속성에서 사용할 수 있는 보낸 사람 ID 필터링 구성에서는 Exchange Server가 실패한 검증을 처리하는 방법만 지정할 수 있습니다.
Exchange Server 2007에서 보낸 사람 ID를 사용하려면 Edge 전송 역할이 구성된 서버의 Exchange Management Console(Exchange 관리 콘솔)을 열고 Anti-spam(스팸 방지) 탭과 Sender ID(보낸 사람 ID)를 차례로 선택한 다음 Actions(동작) 창에서 Enable(사용) 또는 Disable(사용 안 함)을 클릭하여 그림 2와 같이 보낸 사람 ID 에이전트의 상태를 전환합니다. 또한 그림 3과 같이 Exchange 관리 셸을 통해 보낸 사람 ID를 사용하거나 사용하지 않도록 설정할 수도 있습니다.
그림 2 Exchange Server 2007의 보낸 사람 ID 에이전트에 대한 Exchange 관리 콘솔 제어 기능
그림 2 Exchange Server 2007의 보낸 사람 ID 에이전트에 대한 Exchange 관리 콘솔 제어 기능 (더 작게 보려면 이미지를 클릭하십시오.)
그림 2 Exchange Server 2007의 보낸 사람 ID 에이전트에 대한 Exchange 관리 콘솔 제어 기능
그림 2 Exchange Server 2007의 보낸 사람 ID 에이전트에 대한 Exchange 관리 콘솔 제어 기능 (더 크게 보려면 이미지를 클릭하십시오.)
그림 3 Exchange 관리 셸을 통해 보낸 사람 ID 사용 설정
그림 3 Exchange 관리 셸을 통해 보낸 사람 ID 사용 설정 (더 작게 보려면 이미지를 클릭하십시오.)
그림 3 Exchange 관리 셸을 통해 보낸 사람 ID 사용 설정
그림 3 Exchange 관리 셸을 통해 보낸 사람 ID 사용 설정 (더 크게 보려면 이미지를 클릭하십시오.)
Sender ID Properties(보낸 사람 ID 속성) 대화 상자에는 에이전트 상태(사용 또는 사용 안 함)가 반영됩니다. Action(동작) 탭에는 Exchange Server 2003에서 사용할 수 있는 것과 매우 비슷한 옵션이 있습니다(그림 4 참조).
그림 4 Exhange Server 2007의 보낸 사람 ID 에이전트 동작 속성
그림 4 Exhange Server 2007의 보낸 사람 ID 에이전트 동작 속성 (더 작게 보려면 이미지를 클릭하십시오.)
그림 4 Exhange Server 2007의 보낸 사람 ID 에이전트 동작 속성
그림 4 Exhange Server 2007의 보낸 사람 ID 에이전트 동작 속성 (더 크게 보려면 이미지를 클릭하십시오.)
보낸 사람 ID 구현과 기능 측면에서 Exchange Server 2003과 Exchange Server 2007 간에는 큰 차이가 없으며 보낸 사람 ID 필터(Exchange Server 2003)와 보낸 사람 ID 에이전트(Exchange Server 2007) 모두 추출과 확인 작업에 같은 기본 알고리즘을 사용합니다. 가능한 동작 범위도 메시지 삭제(자동 삭제), 메시지 거부(500 수준 SMTP 프로토콜 응답), 보낸 사람 ID 결과로 메시지를 스탬프 처리하고 계속 진행 등으로 같습니다. 이 마지막 옵션은 Exchange Server 두 버전 모두에서 기본 동작입니다.
Exchange Server 2007에서는 FAIL 상태 코드와 TempError 상태 코드가 모두 메시지 거부 동작을 트리거할 수 있지만 Exchange Server 2003에서는 FAIL 상태 코드만 이 동작을 트리거할 수 있습니다. TempError 상태 코드를 가진 메시지에 대해 메시지 거부 동작을 트리거하도록 보낸 사람 ID 에이전트를 명시적으로 구성합니다. 이는 기본적으로 이러한 메시지가 시스템에 받아들여지고 보낸 사람 ID 결과로 스탬프 처리된 다음 처리되기 때문입니다.
이에 대한 구성 옵션은 그래픽 사용자 인터페이스를 통해 제공되지 않으므로 Exchange 관리 셸을 사용하여 TempError 상태 코드에 대한 보낸 사람 ID 동작을 구성해야 합니다. 예를 들어 보낸 사람 ID 에이전트가 TempError 상태 코드를 가진 메시지를 거부하도록 설정하려면 다음 보낸 사람 ID 에이전트 cmdlet을 실행해야 합니다.
Set-SenderIDConfig -TempErrorAction Reject
Exchange Server 2007의 보낸 사람 ID 상태 결과 범위 및 가능한 동작은 Exchange Server 2003 보낸 사람 ID 필터와 비슷하며 그림 5에 나와 있습니다.
Figure 5 Exchange Server 2007의 보낸 사람 ID 상태 및 동작 (Close Figure 5)

보낸 사람 ID 상태 | 설명 | 동작
Neutral | 게시된 보낸 사람 ID 데이터가 명시적으로 결과에 반영되지 않습니다. | StampStatus
Pass | IP 주소가 허용된 집합에 있습니다. | StampStatus
Fail | IP 주소가 허용되지 않은 집합에 있습니다. | StampStatus, Delete 또는 Reject
SoftFail | IP 주소가 허용되지 않은 집합에 있을 수 있습니다. | StampStatus
None | 게시된 데이터가 없습니다. | StampStatus
TempError | DNS 서버를 사용할 수 없는 경우와 같이 일시적인 오류가 발생했습니다. | StampStatus 또는 Reject
PermError | 레코드 형식에 오류가 있는 경우와 같이 복구할 수 없는 오류가 발생했습니다. | StampStatus
Exchange는 보낸 사람 ID 확인에 실패한 메시지만 삭제합니다(이렇게 하도록 구성된 경우). 다른 결과는 메시지 삭제를 트리거하지 않습니다. Neutral, None, SoftFail, TempError 또는 PermError 상태로 지정되는 들어오는 메시지는 적절한 스탬프로 처리되어 추가 스팸 방지 확인을 위해 전달됩니다. 메시지가 복구할 수 없을 정도로 잘못되었고 FROM IP 주소가 누락된 경우 메시지에 보낸 사람 ID 상태로 스탬프 처리할 수 없는 경우가 있습니다. 이 경우 메시지는 삭제되거나 거부되지 않고 보낸 사람 ID 상태를 설정하지 않은 채 이후 처리를 위해 전달되고 이러한 상황을 알 수 있도록 적합한 이벤트가 기록됩니다.
Exchange Server 2007에서는 보낸 사람 ID 확인에서 제외해야 할 보낸 사람 도메인과 Exchange Server 받는 사람을 쉽게 정의할 수 있습니다. 또한 이 구성 옵션은 Exchange 관리 셸을 통해서만 사용할 수 있습니다. 예를 들어 보낸 사람 ID 필터링에서 contoso.com 도메인을 제외하려면 다음 명령을 실행하면 됩니다.
Set-SenderIDConfig -BypassedSenderDomains contoso.com
마찬가지로 보낸 사람 ID 필터링에서 지정된 Exchange Server 받는 사람에게 보내는 메시지를 제외하려면 다음 명령을 실행합니다.
Set-SenderIDConfig -BypassedRecipients user@contoso.com
Exchange Server 2007에서 그래픽 사용자 인터페이스를 통해서는 설정할 수 없지만 Exchange 관리 셸 cmdlet을 통해 설정된 보낸 사람 ID 구성 값은 그림 6과 같이 Exchange 관리 셸에서 Get-SenderIDConfig 명령을 실행하여 쉽게 확인할 수 있습니다.
그림 6 보낸 사람 ID 구성 cmdlet
그림 6 보낸 사람 ID 구성 cmdlet (더 작게 보려면 이미지를 클릭하십시오.)
그림 6 보낸 사람 ID 구성 cmdlet
그림 6 보낸 사람 ID 구성 cmdlet (더 크게 보려면 이미지를 클릭하십시오.)
Exchange 관리 셸을 사용하여 IP 주소와 해당 도메인 이름을 수동으로 빨리 확인할 수 있습니다. 보낸 사람 ID 상태를 확인하려면 다음 명령을 실행합니다.
Test-SenderID -IPAddress <IPAddress>-PurportedResponsibleDomain <SMTPDomain>
도메인이 없으면 그림 7과 같은 결과가 표시됩니다.
그림 7 주소의 보낸 사람 ID 상태 확인
그림 7 주소의 보낸 사람 ID 상태 확인 (더 작게 보려면 이미지를 클릭하십시오.)
그림 7 주소의 보낸 사람 ID 상태 확인
그림 7 주소의 보낸 사람 ID 상태 확인 (더 크게 보려면 이미지를 클릭하십시오.)

보낸 사람 ID의 이점
전자 메일 메시지를 인증하고 사용자가 받는 스팸의 양을 줄이는 분명한 이점 외에도 SIDF는 프로토콜로서의 다른 이점을 제공합니다. Microsoft는 성능, 비용, 배포 및 확장성, 상호 운용성 등의 여러 가지 주요 목표에 초점을 맞추어 SIDF를 개발했습니다.
SIDF는 먼저 전자 메일 보낸 사람을 인증하고 보낸 사람의 평판 점수를 적용할 수 있도록 합니다. 이를 통해 스팸과 스푸핑된 전자 메일 메시지를 상당히 줄이고 알려진 보낸 사람과 트러스트된 보낸 사람이 보내는 합법적인 전자 메일의 전달 가능성을 개선할 수 있습니다. SPF 레코드를 만드는 것이 무료이므로 SIDF를 준수해야 하는 조직에서 해당 목적을 손쉽게 달성할 수 있습니다. 새 표준 조항을 준수해야 하는 조직에서도 해당 작업을 수행할 수 있습니다. SIDF를 사용하면 SPF 레코드를 게시하는 것만큼이나 쉽게 규정을 준수할 수 있습니다.
SIDF는 가능한 경우 기존 소프트웨어 내에서 작동하도록 개발되었으며 다양한 전자 메일 아키텍처와 클라이언트 및 서버 소프트웨어에 사용할 수 있습니다. SIDF를 효과적으로 사용하려면 인증 서비스가 가장 작은 가정용 메일 서버만큼이나 쉽게 가장 큰 ISP의 요구를 충족할 수 있어야 합니다. SIDF는 한 대의 전자 메일 서버에서 수천 대의 전자 메일 서버까지 지원할 수 있으며 전자 메일 서버를 다른 조직에 아웃소싱하는 조직도 지원합니다.
2007년 4월 18-19일 Microsoft와 30개가 넘는 조직 및 파트너로 이루어진 업계 컨소시엄이 미국 매사추세츠주 보스톤에서 Authentication & Online Identity Summit을 개최할 예정입니다. 이틀 간에 걸쳐 진행되는 이 프로그램에서는 사례 연구를 검토하고 보낸 사람 ID에 대한 기술 검토를 제공하며 전자 메일 인증의 비즈니스 가치에 대해 자세히 논의하게 됩니다. 자세한 내용은 aotalliance.org/summit2007을 참조하십시오. 또한 도구와 리소스 등에 대한 내용은 microsoft.com/senderid(영문)와 microsoft.com/korea/exchange를 참조하십시오.

Craig Spiezle은 Microsoft의 Windows Live Safety의 기술 전략 및 계획 담당 이사입니다. Craig는 전자 메일 인증 관련 제품 관리자로서 보낸 사람 ID를 업계에 전도하는 역할을 해왔으며 1992년부터 Microsoft에서 국제 마케팅, 제품 지원 전략, OEM, 신흥 시장 개발 등의 다양한 관리 업무를 담당했습니다.
Alexander Nikolayev는 Microsoft에서 Exchange Server와 Windows Server의 서버 쪽 프로토콜, 전송 코어 및 스팸 방지 구성 요소를 담당하는 프로그램 관리자이며 University of Mary에서 MBA를 취득했습니다. Exchange 팀 블로그인 blogs.technet.com/exchange(영문)에서 Alexander가 게시한 기사를 참조하십시오.


 From the Editor: 더 넓은 도약
From the Editor
더 넓은 도약

TechNet Magazine 은 지금 여러분 손에 들린 멋진 간행물 이상으로 훨씬 멋집니다. 편집부에서는 전 세계 10억 명 이상의 사람들에게 TechNet Magazine의 콘텐츠를 제공하게 될 혁신적인 새 웹 사이트를 만들기 위해 고군분투하는 나날을 보냈습니다. TechNet Magazine은 11월호부터 영어, 스페인어, 프랑스어, 독일어, 러시아어, 중국어 간체, 포르투갈어(브라질)의 7개 언어로 모든 기사를 온라인으로 제공합니다. 이미 제공 중인 영어 이외에 6개 언어를 추가함에 따라 16억 명 이상의 사용자가 모국어로 본지의 콘텐츠를 이용할 수 있게 된 것입니다. 정말 멋진 일이 아닐 수 없습니다.
아직 충분하지 않을 수 있지만 더욱 유용한 사이트를 만들기 위해 다양한 기능을 추가했습니다. 새로운 RSS 피드에는 날짜, 칼럼, 저자 또는 주제별로 콘텐츠를 선택하여 볼 수 있는 사용자 지정 가능한 기능이 있습니다. 이러한 선택 옵션은 다양하게 섞어서 사용할 수 있습니다. 지금 자신만의 RSS 피드를 만들려면 http://technetmagazine.com/rss(영문)를 방문하십시오.
또한 새로운 주제별 페이지도 제공합니다. IT 전문가가 Windows Vista를 준비하는 데 필요한 모든 정보를 보려면 http://technetmagazine.com/windowsvista를 참조하기만 하면 됩니다. 여러분이 전자 메일 관리자라면 technetmagazine.com/exchange(영문)를 확인하십시오. technetmagazine.com/topics(영문)에는 32가지의 흥미로운 주제별 기사가 정리되어 있으며 앞으로 더 추가될 예정입니다. 11월을 기준으로 총 43개의 보안 관련 기사가 게시되어 여러분의 손길을 기다리고 있습니다.
이것이 전부가 아닙니다. 이제 여러분은 TechNet Magazine은 물론 IT 전문가의 세계에 대해 깊은 통찰력을 가질 수 있습니다. TechNet Magazine의 기술 및 감수 편집자인 Joshua Hoffman은 현재 blogs.technet.com/tnmag(영문)에서 본지의 블로그를 운영하고 있습니다. 또한 필자는 매월 TechNet Magazine 사이트인 www.technetmagazine.com/podcast에 포드캐스트를 호스팅하고 있습니다. 각 포드캐스트에서는 단순한 설명을 넘어 기사의 저자와 이야기를 나누며 기사에 관한 추가적인 내용을 들려 드립니다. TechNet Magazine의 최고 집필진이 직접 들려 주는 기사 및 업무 전반에 대한 이야기를 들으실 수 있습니다.
편집팀은 TechNet Magazine을 IT 전문가를 위한 지구상에서 가장 유용한 리소스로 만들기 위해 혼신의 열정을 쏟고 있습니다. 2006년도 만족하지만 여러분을 위해 우리가 할 수 있는 일이 더 있다면 알고 싶습니다. 본지에 전하실 말씀이 있다면 주저하지 마시고 연락 주십시오. 편집부 직통 전자 메일은 tnmag@microsoft.com이며 의견 사서함은 언제나 활짝 열려 있습니다.
£JOSHUA TRUPIN

도움을 주신 Microsoft 기술 전문가: Kevin Allison, Jessica Arnold, Sebastian Bengochea, Naveen Chand, Li Chen, Alpa Dave, Jill Frank, Mihai Jalobeanu, Darcy Jayne, Harry Katz, Kerry Landen, Todd Luttinen, Brett Muzzey, Bruce Payette, Tony Smith, Shawn Thomas, Jim Truher, Scot Vidican.


 Toolbox: IT 전문가를 위한 새로운 제품
Toolbox
IT 전문가를 위한 새로운 제품
Greg Steen

웹 응용 프로그램 스트레스 테스트
WAPT 웹 응용 프로그램 스트레스 도구
www.loadtestingtool.com
인프라의 규모를 적절히 설정하고 왜 사이트를 점검할 때마다 "서버 사용량이 많음"이라는 응답을 받아야 하는지 CEO에게 질문 받는 난감한 순간을 모면하려면 자신이 최근에 출시한 웹 응용 프로그램의 성능을 정확하게 파악하고 있어야 합니다. 상대적으로 비용이 저렴하고 사용하기 쉬운 웹 응용 프로그램 스트레스 및 성능 테스트 도구를 찾는 중이라면 SoftLogica LLC의 WAPT 4.0을 검토해 보는 것이 좋습니다.
이 응용 프로그램은 대부분의 Windows® 버전에서 실행되긴 하지만 이전 버전에는 소켓 제한이 있기 때문에 기능을 완전하게 사용하려면 Windows 2000, Windows XP 또는 Windows Server® 2003에서 실행하는 것이 좋습니다. 가상 사용자를 이용하는 대부분의 성능 테스트 응용 프로그램과 마찬가지로 WAPT의 경우에도 메모리가 커지고 프로세서가 빨라지고 네트워크 대역폭이 커질수록 더 많은 가상 사용자를 시뮬레이션할 수 있습니다.
설명서에는 512MB의 RAM과 Gig-E 인터페이스를 갖춘 PIV 2.4의 경우 최대 약 2,000명의 가상 사용자를 시뮬레이션할 수 있는 것으로 되어 있지만, 이 수치는 테스트하는 응용 프로그램의 종류와 테스트 프로필을 어떻게 설정했느냐에 따라 달라집니다. 테스트를 좌우하는 또 다른 요소는 요청 간의 지연 시간인데 WAPT를 사용할 경우 이 시간을 가상 사용자 프로필에서 사용자 인지 시간(user think time)으로 설정할 수 있습니다.
가상 사용자 프로필을 설정하는 작업이 끝나면(테스트마다 다양한 시나리오가 있을 수 있음) 해당 프로필에 대한 테스트 계획을 수립할 수 있습니다. WAPT에서는 테스트 순서가 초기(Initial), 실제(Main), 최종(Final) 작업의 세 부분으로 나뉩니다. 이는 기능적인 측면보다는 논리적인 측면을 고려하여 작업을 나누어 놓은 것인데, 예를 들어 로그인이나 등록 기능은 초기 작업으로, 그리고 로그아웃 작업은 최종 작업으로 구분하도록 권장합니다. WAPT를 사용하면 요청을 수동으로 입력하거나 통합 브라우저 레코더를 사용하여 해당 프로필을 가진 사용자가 사이트를 탐색하는 방식을 추적할 수 있습니다. 그런 다음 일반 설정으로 넘어가서, 테스트에 적합한 부하를 파악하고 이 부하 값을 고정된 값으로 설정할 것인지 아니면 지정된 시간이 지나면 값을 늘릴지 결정할 수 있습니다. 테스트하는 동안에는 테스트 시나리오에 대한 성능 통계를 실시간으로 볼 수 있으며, 테스트가 완료된 후에는 나중에 검토할 수 있도록 결과를 HTML이나 CSV로 저장할 수 있습니다.
가격: 시스템당 350달러
인프라의 규모를 적절히 설정하고 왜 사이트를 점검할 때마다 "서버 사용량이 많음"이라는 응답을 받아야 하는지 CEO에게 질문 받는 난감한 순간을 모면하려면 자신이 최근에 출시한 웹 응용 프로그램의 성능을 정확하게 파악하고 있어야 합니다. 상대적으로 비용이 저렴하고 사용하기 쉬운 웹 응용 프로그램 스트레스 및 성능 테스트 도구를 찾는 중이라면 SoftLogica LLC의 WAPT 4.0을 검토해 보는 것이 좋습니다.
이 응용 프로그램은 대부분의 Windows® 버전에서 실행되긴 하지만 이전 버전에는 소켓 제한이 있기 때문에 기능을 완전하게 사용하려면 Windows 2000, Windows XP 또는 Windows Server® 2003에서 실행하는 것이 좋습니다. 가상 사용자를 이용하는 대부분의 성능 테스트 응용 프로그램과 마찬가지로 WAPT의 경우에도 메모리가 커지고 프로세서가 빨라지고 네트워크 대역폭이 커질수록 더 많은 가상 사용자를 시뮬레이션할 수 있습니다.
WAPT 웹 응용 프로그램 스트레스 도구
WAPT 웹 응용 프로그램 스트레스 도구 (더 작게 보려면 이미지를 클릭하십시오.)
WAPT 웹 응용 프로그램 스트레스 도구
WAPT 웹 응용 프로그램 스트레스 도구 (더 크게 보려면 이미지를 클릭하십시오.)
설명서에는 512MB의 RAM과 Gig-E 인터페이스를 갖춘 PIV 2.4의 경우 최대 약 2,000명의 가상 사용자를 시뮬레이션할 수 있는 것으로 되어 있지만, 이 수치는 테스트하는 응용 프로그램의 종류와 테스트 프로필을 어떻게 설정했느냐에 따라 달라집니다. 테스트를 좌우하는 또 다른 요소는 요청 간의 지연 시간인데 WAPT를 사용할 경우 이 시간을 가상 사용자 프로필에서 사용자 인지 시간(user think time)으로 설정할 수 있습니다.
가상 사용자 프로필을 설정하는 작업이 끝나면(테스트마다 다양한 시나리오가 있을 수 있음) 해당 프로필에 대한 테스트 계획을 수립할 수 있습니다. WAPT에서는 테스트 순서가 초기(Initial), 실제(Main), 최종(Final) 작업의 세 부분으로 나뉩니다. 이는 기능적인 측면보다는 논리적인 측면을 고려하여 작업을 나누어 놓은 것인데, 예를 들어 로그인이나 등록 기능은 초기 작업으로, 그리고 로그아웃 작업은 최종 작업으로 구분하도록 권장합니다. WAPT를 사용하면 요청을 수동으로 입력하거나 통합 브라우저 레코더를 사용하여 해당 프로필을 가진 사용자가 사이트를 탐색하는 방식을 추적할 수 있습니다. 그런 다음 일반 설정으로 넘어가서, 테스트에 적합한 부하를 파악하고 이 부하 값을 고정된 값으로 설정할 것인지 아니면 지정된 시간이 지나면 값을 늘릴지 결정할 수 있습니다. 테스트하는 동안에는 테스트 시나리오에 대한 성능 통계를 실시간으로 볼 수 있으며, 테스트가 완료된 후에는 나중에 검토할 수 있도록 결과를 HTML이나 CSV로 저장할 수 있습니다.
가격: 시스템당 350달러

서평
Content Networking Fundamentals
www.ciscopress.com
콘텐츠가 가장 중요한 요소입니다. Silvano Da Ros의 Content Networking Fundamentals(Cisco Press, 2006)를 읽으면 사용 중인 콘텐츠 제공 인프라를 개선하는 지름길을 찾을 수 있습니다. 이 책의 표지에는 "콘텐츠 네트워킹의 이론 및 실제 환경에서의 적용을 위한 포괄적인 소개"라고 되어 있는데 이는 이 책의 실제 내용에 딱 맞는 문구입니다. 이 책의 내용이 Cisco의 네트워킹 도구에 초점을 맞추고 있다는 데는 이견의 여지가 없지만, 콘텐츠 네트워킹의 다양한 구성 요소에 대한 이해를 도와 줄 뿐 아니라 콘텐츠 네트워킹의 원리를 구현하는 데 필요한 실용적인 지침을 제시하고 있습니다. 이러한 콘텐츠 네트워킹 원리는 인프라에서 사용되는 콘텐츠 네트워킹 제품의 종류에 상관없이 적용할 수 있습니다.
이 책에서는 먼저 콘텐츠 네트워킹의 다양한 요소를 깊이 있게 살펴보는데, 실제로 콘텐츠 네트워킹을 통해 OSI 모델의 계층 4에서 7까지의 통신 전달 및 성능이 개선됩니다. 그 다음에는 XML, HTML 및 WAP 같은 주요 콘텐츠 표시 형식의 기본 원리를 자세히 설명하고 네트워크 경계에서의 XSLT를 통한 콘텐츠 변환과 스트리밍 미디어의 전달에 대해서도 살펴봅니다. 마지막으로 전역 및 로컬 서버의 부하 분산 및 방화벽 부하 분산에 대한 논의와 함께 확장성과 가용성에 대해 알아보고 Cisco의 콘텐츠 서비스 스위치와 같은 콘텐츠 캐싱 장치가 어떻게 사용되는지 살펴봅니다.
인프라에서 Cisco의 콘텐츠 서비스 스위치를 사용하는 사용자의 경우 보안 콘텐츠를 전환하는 내용이 소개된 장을 읽어 보면 도움이 될 것입니다. 이 장에서는 URL 구성 및 헤더 재작성과 관련된 내용뿐 아니라 SSL(Secure Socket Layer)에 맞게 콘텐츠 서비스 모듈을 구성하는 방법에 대해 자세히 설명합니다. 선호하는 브랜드에 상관없이 네트워킹 전문가라면 누구나 QoS에 관해 설명된 장이 다양한 대기열 메커니즘과 정체 관리를 이해하는 데 도움이 된다는 것을 알 수 있습니다.
이 책은 Cisco Press에서 출간되었기 때문에 Cisco의 하드웨어 구현에 무게를 두고 있지만, 개념조차 파악하기 어려웠던 "콘텐츠 네트워킹"이라는 용어를 사용자의 콘텐츠 제공 인프라에 실제로 적용할 수 있는 방법론을 찾는 데 많은 도움이 됩니다.
가격: 55달러

서비스 모니터링
WebWatchBot
www.exclamationsoft.com/webwatchbot/default.asp
IT 전문가로 성공하기 위한 요건 중 하나는 조직의 최종 사용자보다 먼저 문제를 발견하는(해결까지 할 수 있다면 더할 나위가 없겠지만) 능력입니다. 이를 위해 IT 전문가가 구비해야 할 가장 중요한 도구 하나는 자신이 제공하는 다양한 서비스가 예상대로 실행되는지 확인할 수 있는 효과적인 모니터링 시스템입니다. ExclamationSoft의 WebWatchBot을 사용하면 이러한 목표에 한 발짝 더 다가설 수 있습니다.
이 응용 프로그램은 거의 모든 일반적인 서비스를 모니터링할 수 있습니다. WebWatchBot은 서비스가 실행되고 있는 것을 단순히 확인하는 데서 멈추지 않습니다. WebWatchBot은 서비스를 실제로 테스트함으로써 서비스가 올바르게 작동하고 있는지 확인합니다. 예를 들어 FTP 확인의 경우 파일을 실제로 업로드 및 다운로드할 수 있으며 DNS 모니터링의 경우에는 40개의 서로 다른 쿼리 명령을 실행하여 응답의 문자열을 검색할 수 있고 POP3 및 SMTP 테스트의 경우 실제로 로그인하여 메일 성능을 보고할 수 있습니다.
WebWatchBot
WebWatchBot (더 작게 보려면 이미지를 클릭하십시오.)
WebWatchBot
WebWatchBot (더 크게 보려면 이미지를 클릭하십시오.)
이 외에도 WebWatchBot을 사용하면 트랜잭션에 포함된 일련의 단계를 연결하고, 전체 트랜잭션에 대해 설정된 임계값을 기준으로 대기 시간이 허용치를 넘는 경우나 오류를 보고할 수 있습니다. 또한 이 응용 프로그램은 HTTP 및 HTTPS URL을 모니터링하고 지정된 콘텐츠를 확인할 수도 있습니다. 더 나아가 쿼리를 실행하고 템플릿 형식의 응답을 기준으로 데이터를 확인하는 데이터베이스 모니터를 설정할 수도 있습니다.
가격: 단일 사용자 라이선스당 495.95달러

Greg Steen은 열정적으로 일하는 기술 전문가이자 기업가로서, IT 전문가들이 작업과 개발을 보다 쉽게 수행할 수 있도록 항상 새로운 도구와 방법을 모색합니다.


 Windows PowerShell: 간단한 명령, 강력한 관리
Windows PowerShell
간단한 명령, 강력한 관리
Don Jones
이 칼럼은 Windows PowerShell의 시험판 버전을 기준으로 작성되었습니다. 이 문서에 수록된 모든 정보는 변경될 수 있습니다.

오랜 기다림 끝에 드디어 Windows PowerShell이 출시를 기다리고 있습니다. 이제 Windows 관리자에게 이 소식을 전할 때가 된 것입니다. Windows PowerShell은 다양한 관리 작업을 자동화하여 효과적이고도 효율적으로 작업을 수행할 수 있는 가장 쉽고 유연한 방법을 제공합니다.
그리고 무엇보다도 중요한 사실은 Microsoft에서 Windows PowerShell™을 기반으로 하여 Exchange Server 2007 및 System Center 2007과 같은 제품의 그래픽 관리 콘솔을 만들고 있다는 것입니다. 이 말은 곧 Windows PowerShell 내에서 대부분의 관리 작업을 수행할 수 있게 된다는 것을 뜻합니다. Microsoft에서는 앞으로 더 많은 제품의 관리 기능에 대해 같은 작업을 진행해 나갈 계획입니다. 결국 Windows PowerShell은 거의 모든 Microsoft 서버 제품의 관리 작업에 사용할 수 있는 첫 번째 통합 관리 도구가 될 것입니다. 이 새 칼럼에서는 정기적으로 Windows PowerShell에 대해 설명함으로써 여러분이 Windows PowerShell에 친숙해질 수 있도록 지원하려고 합니다. Windows PowerShell 소프트웨어 사본을 다운로드하십시오.

강력함과 단순함
이름에서 알 수 있듯이 Windows PowerShell은 Windows NT® 3.1부터 있었던 명령 프롬프트(Cmd.exe)와 비슷한 셸입니다. Cmd.exe는 그대로 유지되지만 Windows PowerShell이 있기 때문에 이젠 사용할 이유가 거의 없습니다.
Windows PowerShell은 Cmd.exe와 비슷한 점이 많지만 Windows PowerShell이 훨씬 강력합니다. Cmd.exe와 마찬가지로 Windows PowerShell에도 기본 제공 스크립트 언어가 있지만 Cmd.exe의 기본 배치 언어에 비해 유연성이 훨씬 큽니다. 얼마나 유연하냐구요? Windows PowerShell에서는 대여섯 개의 기본 제공 키워드만으로 구성된 언어를 사용하여 매우 복잡한 작업을 자동화할 수 있습니다.
지금까지는 스크립트에 대한 이야기였지만 보안에 대해서도 이야기해 보지요. Windows PowerShell에는 지난 10여 년 동안 쌓아온 Microsoft의 보안 관련 경험이 녹아 있습니다. 기본적으로 Windows PowerShell은 스크립트를 실행하지 않으며 개별 명령을 대화식으로만 실행할 수 있습니다. 스크립트 기능을 활성화한 경우에는 Windows PowerShell에서 디지털 서명된 스크립트만 실행하도록 지정할 수 있습니다. 이 모든 것은 Windows PowerShell이, 우수한 언어이기는 하지만 악의적인 스크립트를 만드는 데 많이 활용되고 있는 VBScript의 전철을 밟지 않도록 하기 위한 것입니다. 앞으로도 VBScript를 계속 사용할 수 있기는 하지만 그보다는 Windows PowerShell이 다양한 작업에 활용하기 쉬운 도구라는 것을 알게 될 것입니다.
Cmd.exe로 수행했던 거의 모든 작업은 Windows PowerShell로도 수행할 수 있습니다. 예를 들어 ipconfig를 실행하여 동일한 결과물을 얻을 수 있습니다. 그러나 Windows PowerShell은 외부 실행 파일이 아닌 완전히 새로운 명령인 cmdlet을 지원합니다. 이러한 cmdlet은 "커맨드 렛"이라고 읽으며 Windows PowerShell 내부에 구현되어 있습니다. Windows PowerShell을 시작할 때 가장 유용하게 사용할 수 있는 cmdlet을 보려면 화면 옆쪽의 "바로 사용할 수 있는 유용한 10가지 cmdlet"을 참조하십시오.
바로 사용할 수 있는 유용한 10가지 cmdlet
  • Get-Command는 사용 가능한 모든 cmdlet을 검색합니다.
  • Get-Help는 cmdlet 및 개념에 대한 도움말 정보를 표시합니다.
  • Get-WMIObject는 WMI를 사용하여 관리 정보를 검색합니다.
  • Get-EventLog는 Windows 이벤트 로그를 검색합니다.
  • Get-Process는 단일 활성 프로세스 또는 활성 프로세스 목록을 검색합니다.
  • Get-Service는 Windows 서비스를 검색합니다.
  • Get-Content는 텍스트 파일을 읽고, 각 줄을 자식 개체로 취급합니다.
  • Add-Content는 텍스트 파일에 내용을 추가합니다.
  • Copy-Item은 파일, 폴더 및 기타 개체를 복사합니다.
  • Get-Acl은 ACL(액세스 제어 목록)을 검색합니다.
Windows PowerShell에서 제공되는 전체 cmdlet 목록을 보려면 windowssdk.msdn.microsoft.com/en-us/library/ms714408.aspx를 참조하십시오.
모든 cmdlet은 동사-명사 형식의 표준 이름을 갖기 때문에 쉽게 알아보고 기억할 수 있습니다. 예를 들어 Get-Command cmdlet을 실행하면 사용할 수 있는 모든 cmdlet이 나열됩니다. 관리자에게 가장 유용한 cmdlet은 아마도 Get-WMIObject일 것입니다. Server2에서 실행되고 있는 서비스 팩을 알고 싶으면 다음과 같이 명령을 실행하면 됩니다.
Get-WMIObject Win32_OperatingSystem –Property ServicePackMajorVersion
 –Computer Server2
VBScript를 사용하여 이 같은 정보를 검색하려면 여러 줄의 코드를 작성해야 합니다. 다른 cmdlet 또한 서비스(Start-Service, Stop-Service 등), 프로세스(Stop-Process 등), 파일(Rename-Item, Copy-Item, Remove-Item, Move-Item 등) 및 여러 가지 작업에 사용할 수 있습니다. 이 중 많은 cmdlet은 별칭이라는 바로 가기 이름을 가집니다. Get-WMIObject는 gwmi라고만 입력해도 됩니다. Get-Alias를 실행하면 이러한 바로 가기 이름을 보여 주는 목록이 표시됩니다.

개체 지향이 중요한 이유
Microsoft® .NET Framework를 기반으로 하는 Windows PowerShell은 완전히 개체 지향적입니다. 일반적으로 개체 지향이라고 하면 소프트웨어 개발자만 좋아하지만 이 경우에는 관리자도 개체 지향 특성으로 인해 많은 시간을 절약할 수 있습니다. 왜냐하면 관리자가 텍스트 기반 셸 내에서 다양한 개체와 관련된 작업을 직접 수행할 수 있기 때문입니다. 다음 예를 살펴보겠습니다.
Get-Process | Sort-Object pm –desc | Select-Object –first 10
이 예에서는 파이프(나중에 자세히 설명함)로 구분된 세 개의 다른 cmdlet이 한 줄에 들어 있습니다. 첫 번째 cmdlet은 실행 중인 모든 프로세스를 검색한 다음 검색된 개체를 파이프를 통해 Sort-Object에 전달합니다. 이 두 번째 cmdlet은 각 프로세스 개체의 pm(실제 메모리라는 의미) 속성을 정렬하여 내림차순으로 배치합니다. 정렬된 프로세스 개체 컬렉션은 파이프를 통해 처음 10개의 개체를 선택해서 표시하는 Select-Object에 전달됩니다. 결과는 무엇일까요? 이 간단한 코드의 결과로 그림 1에서 보듯이 시스템에서 실제 메모리를 가장 많이 사용하는 상위 10개 구성 요소가 표시됩니다. 이 방법은 문제 해결을 위해 빠르게 상황을 검토할 수 있는 매우 효율적인 방법입니다.
그림 1 간단한 cmdlet으로 문제 해결
그림 1 간단한 cmdlet으로 문제 해결 (더 작게 보려면 이미지를 클릭하십시오.)
그림 1 간단한 cmdlet으로 문제 해결
그림 1 간단한 cmdlet으로 문제 해결 (더 크게 보려면 이미지를 클릭하십시오.)
Windows PowerShell을 효과적으로 사용하기 위해서는 파이프(일반적으로 키보드의 백슬래시 키에 있는 세로 줄 문자)를 반드시 사용해야 합니다. 이 문자를 사용하면 한 cmdlet에서 다른 cmdlet에 개체를 전달하여 결과 값을 조정하거나, 결과의 표시 형식을 지정하는 등의 작업을 수행할 수 있습니다. 이 메커니즘은 모든 cmdlet이 일반 텍스트 대신 개체를 반환하므로, 이후의 cmdlet이 온전한 개체를 가지고 작업을 수행할 수 있기 때문에 가능합니다.
Windows PowerShell에서는 변수에도 개체 개념이 적용될 정도로 개체의 사용이 광범위합니다. 또한 변수를 미리 선언할 필요 없이 변수 이름 앞에 달러 기호($)를 넣고 사용하면 됩니다. 반드시 필요한 것은 아니지만 변수에 넣을 데이터 형식을 Windows PowerShell에 알려 줄 수도 있습니다. 이렇게 하면 Windows PowerShell에서 해당 변수가 매우 강력한 .NET Framework 형식 중 하나에 매핑되기 때문에 여러 가지 추가적인 기본 기능을 사용할 수 있습니다. 예를 들어 컴퓨터 이름을 입력 받아 해당 컴퓨터의 서비스 팩 버전을 검색하려는 경우, 컴퓨터 이름을 입력하는 사용자가 두 개의 백슬래시(예: \\Server2)를 포함할 수 있습니다. 그러나 Get-WMIObject cmdlet의 경우 백슬래시가 필요하지 않기 때문에 다음과 같이 컴퓨터 이름을 String 변수에 저장한 다음 Replace 메서드를 사용하여 백슬래시를 빈 문자열로 바꿀 수 있습니다.
[string]$c = Read-Host "Enter computer name"
$c = $c.Replace("\","")
    Get-WMIObject Win32_OperatingSystem
    –Property  ServicePackMajorVersion
    –Computer $c
–Computer 매개 변수에 대한 값은 $c 변수에 지정되어 있습니다. 이 변수는 처음부터 문자열로 만들어졌기 때문에 Replace 메서드를 포함한 .NET Framework String 형식의 모든 기능을 사용할 수 있습니다. 물론 이 모든 기능을 배우려면 많은 시간이 걸리겠지만 예를 이용하면 쉽게 배울 수 있습니다. Windows PowerShell 자체에서도 쉽게 배울 수 있는 방법이 제공됩니다. 예를 들어 $c = $c.(마침표에 주의)를 입력하고 Tab 키를 누르면 Windows PowerShell에 String 형식의 첫 번째 메서드인 Clone()이 표시됩니다. Tab 키를 계속 누르고 있으면 사용할 수 있는 모든 메서드가 차례로 표시됩니다. 이 방법을 통해 String으로 수행할 수 있는 작업에 대한 모든 정보를 볼 수 있습니다.
간단한 작업을 예로 들어 보겠습니다. 파일에서 한 줄에 하나의 이름이 들어 있는 컴퓨터 이름 목록을 읽은 다음 각 컴퓨터의 서비스 팩 번호를 표시하는 작업을 수행하려면 VBScript에서는 10줄 이상의 코드가 필요하고, cmd.exe에서는 복잡한 배치 파일을 사용해야 하지만 Windows PowerShell에서는 단 한 줄만으로 이 작업을 수행할 수 있습니다.
Get-Content "c:\computers.txt" | foreach
{ $_; gwmi Win32_OperatingSystem -prop
ServicePackMajorVersion -comp $_ }
Get-Content cmdlet은 C:\Computers.txt의 내용을 읽습니다. 파일의 각 줄은 자체 권한으로 개체가 됩니다. 이 개체, 즉 컴퓨터 이름 컬렉션은 파일을 통해 ForEach-Object cmdlet의 별칭인 foreach 명령에 전달됩니다. 중괄호 내의 명령이 파이프를 통해 전달된 각 개체에 대해 한 번씩 실행됩니다. 이 예에서는 각 컴퓨터 이름에 대해 한 번씩 명령이 실행됩니다. 특수 $_ 변수에 현재 개체(현재 컴퓨터 이름)가 포함됩니다.
중괄호 내에는 실제로 두 개의 명령이 있습니다. 첫 번째 명령은 단순히 $_의 내용을 출력하여 현재 컴퓨터 이름을 표시합니다. 두 번째 명령은 앞에서 살펴보았던 gwmi입니다. 이렇게 해서 파일에 나열된 모든 컴퓨터의 서비스 팩 버전 목록을 얻을 수 있습니다. 이 모든 작업이 한 줄로 된 비교적 간단한 명령으로 완료되었습니다.
–Property 및 –Computer 매개 변수 이름에는 약어가 사용되었습니다. Windows PowerShell에서는 매개 변수 이름을 고유하게 구별할 수만 있으면 됩니다.

가독성 및 재사용
그러나 모든 명령과 매개 변수를 한 줄로 작성하면 가독성이 떨어집니다. Windows PowerShell에서는 가독성을 높일 수 있도록 여러 줄로 나누어서 입력할 수 있기 때문에 스크립트를 작성하지 않고 셸에 직접 입력할 수 있습니다. 다음 예를 살펴보겠습니다.
PS C:\> $names = get-content "c:\computers.txt"
PS C:\> foreach ($name in $names) {
>> $name
>> gwmi Win32_OperatingSystem -prop ServicePackMajorVersion -comp $name
>> }
>>
이 예에서는 파일의 내용이 변수 $names에 저장됩니다. 이 예에서도 foreach가 사용되기는 하지만 파이프라인을 통해 입력되지 않기 때문에 ($name in $names)처럼 루프의 실행 대상이 되는 개체의 컬렉션과 각 개체를 저장할 변수를 지정해야 합니다. 나머지 부분은 모두 동일하며 이제 Enter 키를 누르면 코드가 실행되어 결과가 표시됩니다.
이 코드를 반복해서 사용하려는 경우 이 코드를 함수로 만들 수 있습니다. 다시 한번 이 코드를 셸에 직접 입력합니다.
PS C:\> function Get-ServicePacks ($file) {
>> $names = get-content $file
>> foreach ($name in $names) {
>> $name
>> gwmi win32_operatingsystem -prop servicepackmajorversion -comp $name
>> }
>> }
>>
위에서 볼 수 있는 것처럼 실제로 변경된 부분이 많지 않습니다. 이 코드는 이전 예를 Get-ServicePacks(Windows PowerShell 동사-명사 명명 규칙에 따름)라는 함수로 묶었을 뿐입니다. 이 함수에서는 함수를 실행할 때 다른 파일을 지정할 수 있도록 이전 예의 Get-Content cmdlet 대신 $file이라는 입력 매개 변수를 사용했습니다. 이제 함수를 정의했으므로 cmdlet을 호출하는 것과 동일한 방식으로 함수의 이름을 호출하여 실행하고 입력 매개 변수를 전달합니다.
PS C:\> Get-ServicePacks c:\computers.txt
그림 2에서는 실행 결과를 보여 줍니다.
이 함수는 Windows PowerShell 인스턴스가 실행 중인 동안에만 존재한다는 단점을 갖고 있습니다. 셸을 닫으면 함수가 제거됩니다. Windows PowerShell이 시작될 때마다 실행되는 자동 실행 스크립트의 일종인 Windows PowerShell 프로필에 함수를 복사할 수 있습니다. 이렇게 하면 열려 있는 모든 Windows PowerShell 창에서 함수를 사용할 수 있습니다. 원하는 경우에는 함수를 독립형 스크립트로 만들어서 스크립트의 경로와 파일 이름을 입력하는 것만으로도 함수를 실행할 수 있습니다.
그림 2 Get-ServicePacks 함수의 실행 결과
그림 2 Get-ServicePacks 함수의 실행 결과

파일(또는 폴더)로 구성된 세상
Windows PowerShell에는 함수와 cmdlet 외에도 많은 것이 있습니다. 다른 기능의 간단한 예로, 파일 관리에 대해 살펴보겠습니다. Cmd.exe에서 C:를 입력하여 C 드라이브로 전환한 다음 cd \test를 입력하여 C:\Test 폴더로 이동하는 방식으로 드라이브와 폴더를 탐색하는 방법을 많이 사용해 왔을 것입니다. Windows PowerShell에서도 이와 동일한 방법으로 탐색 작업을 수행할 수 있습니다. Windows PowerShell에서는 cd가 Set-Location cmdlet의 별칭입니다.
사용할 수 있는 모든 드라이브를 나열하는 cmdlet인 Get-PSDrive를 실행합니다. 일반적으로 볼 수 있는 C:, D: 및 A: 드라이브뿐만 아니라 Cert, Env, HKCU 및 HKLM이라는 여러 가지 이름이 표시됩니다. Windows PowerShell에서는 실제로 다양한 유형의 저장소 자원이 "드라이브"로 표시되기 때문에 로컬 인증서 저장소, 환경 변수 및 레지스트리를 익숙한 파일 형식의 탐색 인터페이스를 통해 사용할 수 있습니다.
Set-Location HKLM: (약어를 좋아하는 경우 cd hklm:)을 입력하고 Enter 키를 눌러 HKEY_LOCAL_MACHINE 레지스트리 하이브로 이동합니다. 그런 다음 cd software\microsoft를 실행하여 SOFTWARE\Microsoft 키로 이동합니다. Get-ChildItem cmdlet의 별칭인 dir을 사용하여 레지스트리의 이 부분에 있는 하위 키를 나열할 수 있습니다. 키를 제거하려는 경우 파일이나 폴더를 제거하듯이 del을 사용하여 키를 제거합니다. 필수 키를 제거하거나 레지스트리를 잘못 수정할 경우 심각한 문제가 발생할 수 있으므로 신중해야 합니다.
이와 같은 유연성은 모두 레지스트리 및 인증서 저장소와 같은 자원을 파일 시스템과 비슷한 형식으로 매핑하는 공급자가 제공하는 것입니다. Microsoft는 추가 공급자를 통해 Windows PowerShell을 확장할 계획으로, Exchange Server 저장소를 파일 시스템처럼 탐색하는 등의 기능을 제공하려고 합니다. 이 기술은 Windows에 사용되는 다양한 저장소를 동일한 형태로 표시할 수 있고 이미 익숙해져 있는 명령 시스템과 기술을 사용하여 관리할 수 있다는 점에 매우 중요한 의미를 갖습니다.

안전성을 고려한 설계
이미 언급했듯이 Windows PowerShell은 보안과 안전성을 고려하여 설계되었습니다. Windows PowerShell의 기본 보안 기능은 실행 정책입니다. 기본적으로 이 정책은 "Restricted"로 설정되며, Get-ExecutionPolicy cmdlet을 실행하여 확인할 수 있습니다. Restricted 모드에서는 스크립트가 실행되지 않습니다. 이 모드가 기본 모드이므로 Windows PowerShell은 기본적으로 스크립트를 실행하는 데 사용할 수 없습니다.
Set-ExecutionPolicy cmdlet을 사용하여 다른 모드를 지정할 수 있습니다. 개인적으로 RemoteSigned 모드를 권장합니다. 이 모드에서는 디지털 서명 없이 로컬 스크립트(원격 스크립트는 해당되지 않음)를 실행할 수 있으므로 가장 손쉽게 스크립트를 개발하고 테스트할 수 있습니다. AllSigned 모드에서는 신뢰할 수 있는 게시자가 발행한 인증서를 사용하여 디지털 서명된 스크립트만 실행할 수 있습니다. 마지막으로 Unrestricted 정책에서는 모든 스크립트가 실행됩니다. 이 정책을 적용하면 Windows PowerShell에서 악의적인 스크립트가 자유롭게 실행되어 컴퓨터에 손상을 줄 수 있으므로 이 정책은 사용하지 않는 것이 좋습니다. 실행 정책은 로컬 정책에 우선하는 그룹 정책을 통해서도 제어할 수 있습니다. 그룹 정책 설정이 로컬 설정에 우선하는 경우 Set-ExecutionPolicy가 경고 메시지를 표시합니다.
또한 Windows PowerShell에서는 사용자가 경로를 지정하지 않은 경우 현재 디렉터리에서 스크립트가 실행되지 않습니다. 이것은 명령 하이재킹을 막기 위한 것입니다. 누군가가 IPConfig.ps1(PS1은 Windows PowerShell 스크립트 파일의 확장명임)이라는 스크립트를 만들었다고 가정합시다. 이러한 파일을 현재 폴더에서 실행할 수 있다면 Windows 프로그램인 Ipconfig.exe를 실행하기 위해 ipconfig를 입력했을 때 이 사용자가 만든 스크립트가 실행되는 위험이 존재합니다. Windows PowerShell에서는 스크립트가 현재 폴더에서 실행되지 않기 때문에 이러한 실수가 발생할 수 없습니다. 스크립트를 현재 폴더에서 실행하려면 .\myscript와 같이 경로를 지정하면 됩니다. 현재 폴더에 대한 명시적 참조는 셸 명령이 아닌 스크립트의 실행을 보장합니다.
또한 Windows PowerShell은 보다 안전한 실험 방법을 제공합니다. 예를 들어 다음과 같은 예를 살펴보겠습니다. 이 코드는 절대 실행하지 마십시오.
Get-Process | Stop-Process
Get-Process cmdlet은 프로세스 개체 컬렉션을 만들며, 이 컬렉션은 파이프를 통해 Stop-Process cmdlet에 전달되어 해당 프로세스가 실제로 중지됩니다. 결과적으로 중요한 Windows 프로세스가 종료되면서 약 5초 후에 블루 스크린 중지 오류가 발생합니다. 하지만 이러한 cmdlet을 실제로 실행하지 않고서도 다음과 같이 -Whatif 매개 변수를 추가하면 발생하는 작업을 매우 쉽게 확인할 수 있습니다.
Get-process | Stop-Process -Whatif
Windows PowerShell에서 이 코드를 실행할 때 cmdlet이 실제로 실행되지는 않지만 cmdlet으로 인해 수행되는 내용이 표시됩니다. 별칭 help를 사용하여 액세스할 수 있는 Windows PowerShell의 온라인 도움말 시스템에는 -Whatif 매개 변수에 대한 설명이 아직까지 포함되어 있지 않지만 기억해 두시기 바랍니다. 이 매개 변수는 스크립트와 cmdlet을 실제로 실행하지 않고 테스트를 통해 결과를 확인할 수 있기 때문에 잠재적 위험이나 손상을 걱정하지 않아도 되는 유용한 도구입니다.

결론
이 Windows PowerShell 버전에서 다루지 않은 기능 중에서 가장 중요한 기능은 ADSI(Active Directory® Services Interface)에 대한 지원일 것입니다. Windows PowerShell에는 Active Directory 및 다른 디렉터리 서비스와 함께 사용할 수 있는 매우 강력한 .NET 클래스가 있기는 하지만 편리한 Get-ADSIObject cmdlet이 아직 없기 때문에 디렉터리 개체 작업이 약간 어렵습니다.
또한 Windows PowerShell은 동일한 작업을 수행할 수 있는 매우 다양한 방법을 제공합니다. 좋은 일이기는 하지만 특정 작업에 대해 5-6개의 다른 예를 통해 작동 방법을 익혀야 하기 때문에 Windows PowerShell을 배우는 데 약간의 혼란을 느낄 수 있습니다.
이 모든 것은 시간이 지남에 따라 해결될 것이며 Windows PowerShell 팀은 지속적으로 제품에 기능을 추가해 나갈 것입니다. 이 같은 정보를 지속적으로 확인하고 싶으면 Windows PowerShell 팀의 블로그(영문)를 참조하십시오.

Don Jones는 ScriptingAnswers.com의 창립자이자 Windows PowerShell: TFM(SAPIEN Press, 2006)의 공동 저자입니다. 문의 사항이 있으시면 don@scriptinganswers.com으로 연락하십시오.


 Post Mortem: Exchange 5.5에서 마이그레이션
Post Mortem
Exchange 5.5에서 마이그레이션
Whitney Roberts

프로젝트
켄터키 교육부는 이전에 구현한 Microsoft® Exchange Server 5.5를 Exchange Server 2003으로 마이그레이션해야 했습니다. 기존의 시스템은 매년 600,000명 가량의 교직원, 교수 및 학생을 지원하고 있었습니다.
프로젝트 담당자
이 프로젝트는 KiZAN Technologies 컨설턴트의 지원 하에 켄터키 교육부 산하 교육 기술부(OET)가 담당하였습니다. OET 직원은 기존에 구현된 Exchange 5.5에 대한 관리를 담당했으며 매일 Exchange 서버를 실행하는 작업은 학구의 현지 직원이 담당했습니다.
당면 문제
켄터키 교육부는 켄터키 주 내 178개 학구의 기술적인 방향성을 결정하고 있습니다. 이들 178개 학구는 WAN을 통해 연결되어 있지만 각 학구가 Exchange 5.5 서버를 호스팅하여 자체적으로 관리하고 있으므로 업그레이드도 개별적으로 진행해야 했습니다. 새로운 업그레이드에서는 Outlook® 2003 캐시 모드 클라이언트, 개선된 OWA(Outlook Web Access) 환경, 표준화된 전자 메일 주소 지정 스키마 등을 지원합니다.
당시 많은 학구가 새로운 전자 메일 서버/클라이언트 인프라를 구축하는 동시에 학생들에 대한 전자 메일 지원 기능을 추가하고 있었는데 켄터키 주와 연방 정부의 정책은 학생 신상 정보의 보호와 이러한 정보의 해당 학구 외부 유출 금지를 요구했습니다.
계획
ADC(Active Directory® Connector)를 사용할 수 없었으므로 우리는 새로운 Exchange 조직을 만들어 이 조직으로 마이그레이션했습니다. 전자 메일 주소를 표준화한다는 것은 각 학구와 400개가 넘는 새로운 받는 사람 정책 모두에 대해 이를 식별하는 하위 도메인을 새로 만든다는 것을 의미했습니다. 학생 주소를 보호하기 위해서는 GAL(전체 주소 목록) 시스템을 만든 다음 각 학구의 사용자 지정 주소 목록을 만들어야 했습니다.
실제 마이그레이션 작업에는 새로운 하드웨어를 준비하고, 학구 구성원 자격 및 사용자 유형을 기준으로 사서함을 만들어 구성한 다음 확장 특성을 설정하여 사용자가 적절한 주소 목록에 나타나도록 설정하는 작업이 수반되었습니다.
우리는 잘못 구성된 계정 특성이나 그룹 구성원 자격을 찾고 이를 수정하며 주소 표시 요구 사항을 준수하는 새로운 사서함을 제공하는 Visual Basic® 기반 응용 프로그램을 만들었습니다. 이 응용 프로그램은 178개 학구 모두에 배포되어 학구 서버에서 정기적으로 실행됩니다.

배경
언뜻 봐서는 이러한 작업이 힘이 들거나 기술적으로 어려워 보이지 않을 수도 있습니다. 하지만 이 프로젝트의 비즈니스 규칙과 비즈니스 요구 사항은 상상을 초월했습니다.
과거 수년 동안 표준을 분산해서 관리했을 뿐만 아니라 그 표준이 마구 뒤섞임에 따라서 OET의 관리와 지원이 반드시 필요한 수많은 문제들이 누적되었습니다. 뿐만 아니라 OET는 기존에 구현된 Exchange 5.5가 학구와 교육부의 요구 사항을 동시에 충족하는가라는 문제도 검증해야 했습니다. 이는 학생의 전자 메일을 활용하는 학구의 경우 학생 신상 정보가 주 및 연방 정부의 규정(ed.gov/policy/gen/guid/fpco/ferpa/index.html 참조)에 정해진 대로 해당 학구 외부에는 공개되지 않아야 하며 적절히 보호되어야 한다는 것을 의미했습니다.
Exchange 5.5의 경우, 이러한 규정을 따르게 되면 학구 내의 학생 신상 정보를 다른 학구 또는 GAL 데이터를 공유하는 다른 기관으로 복제할 수 없게 됩니다. 따라서 178개의 Exchange 5.5 사이트 각각에 대해 학생을 숨기고 목록을 복제하고 학생을 다시 표시한 다음 주소 목록을 다시 가져오는 방법으로 가져오기/내보내기 작업을 수동으로 수행해야 했습니다. 이 경우 학생 신상 정보를 소유하는 학구에서는 자기 학구의 학생 데이터와 직원 데이터를 모두 볼 수 있습니다. 하지만 다른 학구에 대해서는 해당 학구의 직원 데이터만 볼 수 있습니다.
기존 시스템의 장단점을 고려해 보았을 때 메시징 인프라를 업그레이드하려면 몇 가지 조건을 충족해야 했습니다. 무엇보다도 켄터키 교육부는 보편적이며 읽을 수 있는 SMTP 명명 구성표를 기반으로 조직 전체의 메시징 인프라를 표준화하고자 했습니다. 이러한 구성표는 교직원과 학생에게 별도의 SMTP 주소 공간을 제공할 수 있어야 했습니다.
또한 새로운 시스템은 개별 학구가 더 이상 메시징을 관리하거나 그 가용성에 대해 책임지지 않도록 중앙 관리 서비스를 제공해야 했습니다. 이는 장애 복구, 메일 흐름, 헬프 데스크 지원 요청 해결 등이 중앙에서 관리된다는 것을 의미했습니다. 따라서 새로운 시스템은 특정 사용자의 지리적 위치나 소속된 학구에 관계없이 모든 학구의 사용자 구성을 표준화하는 중앙 집중화된 방법을 제공해야 했습니다.
더 나아가 새로운 시스템은 모든 학구가 공통된 통합 네임스페이스를 바탕으로 모바일 장치와 웹을 통해 전자 메일에 안전하게 액세스할 수 있도록 지원해야 했습니다.
기존의 Exchange 5.5 시스템에서는 대부분 구현되어 있지 않은 이러한 요구 사항을 고려해 보았을 때 Exchange 2003으로의 업그레이드는 그 여정이 매우 험난해 보였습니다.

솔루션 구성 요소
이러한 비즈니스 요구 사항을 충족하기 위해 Exchange에서 사용할 수 있는 몇 가지 옵션을 배포에 포함하기로 결정되었습니다.
표준화의 부재와 Exchange 5.5 환경의 방대한 규모로 인해 ADC는 사용하지 않기로 했습니다. 대신 새로운 Exchange 조직을 만들어 이 조직으로 마이그레이션했습니다.
각 학구의 교직원 및 학생의 전자 메일 주소를 정리하고 표준화하는 과정에서 400개가 넘는 받는 사람 정책이 만들어졌습니다. 비즈니스 요구 사항을 충족하려면 각 학구를 식별하는 고유한 하위 도메인을 만들 뿐 아니라 학생을 식별하는 규칙도 지정해야 했습니다. 예를 들어 쉘비 카운티의 경우 주 하위 도메인이 shelby.kyschools.us입니다. 각 학구의 학생에게는 stu.라는 하위 도메인이 지정되므로 쉘비 카운티의 학생은 stu.shelby.kyschools.us라는 주소를 사용하게 됩니다.
학생 주소는 해당 학생이 속한 학구 내에서만 표시되어야 하는 반면 직원 주소는 모든 학구에 표시되어야 한다는 조건도 충족해야 했습니다. 이는 그림 1과 그림 2에 나온 것처럼 GAL과 사용자 지정 주소 목록으로 구성된 정교한 시스템을 만들어야 함을 의미했습니다. Exchange 2003으로 마이그레이션할 경우 사용 권한을 통해 주소 목록을 안전하게 보호하고 그룹 구성원 자격을 통해 개별 주소 목록에 대한 액세스를 제어할 수 있다는 장점이 있습니다. 따라서 이 기능을 적절하게 활용하여 직원용과 학생용으로 각각 하나씩 학구 수준 보안 그룹을 두 개 만든 다음 해당 학구 직원과 학생의 GAL 및 주소 목록에 보안을 설정하여 특정 학구 내의 사용자 계정만 특정 주소 목록에 액세스할 수 있도록 설정하였습니다. 기본 GAL과 주소 목록을 제거한 다음 각 주소 목록의 ACL(액세스 제어 목록)에 Everyone과 Authenticated Users 그룹이 표시되지 않도록 만들어 특정 학구의 특정 사용자 유형이 볼 수 있는 주소 목록을 미리 선택할 수 있었습니다.
그림 1 역할 기반 사용자 지정 주소 목록
그림 1 역할 기반 사용자 지정 주소 목록 (더 작게 보려면 이미지를 클릭하십시오.)
그림 1 역할 기반 사용자 지정 주소 목록
그림 1 역할 기반 사용자 지정 주소 목록 (더 크게 보려면 이미지를 클릭하십시오.)
하지만 사용 권한을 통해서는 주소 표시 문제의 일부만 해결할 수 있었습니다. 이제 어떤 주소 목록에 어떤 사용자가 표시되도록 할지를 제어하는 방법을 알아내야 했습니다. 이에 따라 직원과 학생의 표시 여부를 조회할 수 있게 해 주는 기본 LDAP(Lightweight Direct Access Protocol) 쿼리를 작성한 다음 각 주소 목록과 GAL에 맞게 이 쿼리를 사용자 지정하게 되었습니다. 예를 들어 쉘비 카운티의 직원 GAL을 조회하는 LDAP 쿼리는 쉘비 카운티에 속한 직원과 학생 및 켄터키 주의 다른 모든 학구에 소속된 모든 직원(학생은 제외됨)을 보여 줍니다. 쉘비 카운티의 학생 GAL에는 쉘비 카운티의 직원과 학생만 표시되고 켄터키 주의 다른 학구의 직원이나 학생은 표시되지 않습니다. 이 쿼리를 조직의 모든 학구에 대해 반복해서 실행했습니다. 그림 3은 이 복잡한 마이그레이션을 수행하는 데 사용된 몇 가지 LDAP 쿼리 예를 보여 줍니다.
Figure 3 주소 목록 LDAP 쿼리 (Close Figure 3)

직원 GAL LDAP 쿼리
(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(|(extensionattribute15=15)(&(extensionattribute14=<districtNumber>)
(extensionattribute15=20))(&(extensionattribute14=<districtNumber>)
(extensionattribute15=14)))))
학구 주소 목록 LDAP 쿼리
(&(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(&(extensionattribute14=<districtNumber>)(extensionattribute15=15)))))
학구 학생 주소 목록 LDAP 쿼리
(&(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(&(extensionattribute14=<districtNumber>)(extensionattribute15=20)))))
학구 직원 오프라인 주소 목록 LDAP 쿼리
(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(|(extensionattribute15=15)(&(extensionattribute14=<districtNumber>)
(extensionattribute15=20))(&(extensionattribute14=<districtNumber>)
(extensionattribute15=14)))))
그림 2 직원과 학생을 분리하는 전역 주소 목록
그림 2 직원과 학생을 분리하는 전역 주소 목록 (더 작게 보려면 이미지를 클릭하십시오.)
그림 2 직원과 학생을 분리하는 전역 주소 목록
그림 2 직원과 학생을 분리하는 전역 주소 목록 (더 크게 보려면 이미지를 클릭하십시오.)
Exchange 사용자 속성 extensionAttribute14(사용자 지정 특성 14)와 extensionAttribute15(사용자 지정 특성 15)에 대한 사용자 지정 값이 이러한 LDAP 쿼리를 가능하게 만든 메커니즘이었습니다. 켄터키 주의 모든 직원과 학생에 대해 extensionAttribute14에는 특정 값을 사용하여 사용자 유형을 지정했고 extensionAttribute15에는 고유 값을 사용하여 직원이나 학생이 소속된 학구를 표시했습니다. 각 학구에는 고유 값을, 그리고 각 사용자 유형에는 동일한 값을 사용함으로써 각 학구의 각 사용자 유형에 필요한 정보를 정확하게 주소 목록에 표시할 수 있었습니다.
이러한 주소 목록은 캐시되지 않은 모드의 Outlook 또는 OWA를 통해 전자 메일에 액세스하는 사용자에게도 올바르게 작동했습니다. 이 프로젝트에서는 msExchQueryBaseDN 특성을 사용함으로써 각 사용자에게 OWA에서 올바른 주소 목록이 표시되도록 할 수 있었습니다. 하지만 캐시 모드에서 Outlook을 실행하는 사용자는 또 다른 문제에 직면했습니다. Outlook에서는 사용자 지정 GAL을 OAB(오프라인 주소록)로 인식하지 않으므로 GAL이 복제된 주소 목록을 추가로 만들어야 했습니다. 그런 다음 Outlook 캐시 모드 사용자를 위해 적절한 OAB 주소록을 사용하여 각 학구의 사서함 저장소를 구성했습니다. 이 솔루션으로 전체 1,500개가 넘는 주소 목록을 관리함으로써 총 178개 학구의 다양한 사용자 유형에 대해 완벽한 기능을 제공할 수 있었습니다.

규정 준수
구조가 실제 환경에서 올바르게 작동하도록 하기 위해 이 구조가 새로 확립된 표준을 철저하게 준수하는지 검증해야 했습니다. 조직에서 Exchange를 사용하는 모든 사용자가 직면하게 되는 몇 가지 어려운 작업이 있었습니다. 이는 모든 학구의 Exchange 서버에서 각 사용자를 정확하게 찾을 수 있어야 할 뿐만 아니라 각 사용자가 정확한 주소 목록에 표시되어야 하기 때문이었습니다.
적절한 주소 목록을 열 수 있는 권한은 보안 그룹을 통해 부여되므로 Exchange 사용자는 학구 도메인 내의 적절한 보안 그룹의 구성원이 되어야 했습니다. 또한 Exchange 사용자의 경우 학구 및 OU(조직 구성 단위) 구성원 자격을 기준으로 msExchQuerybaseDN 특성을 올바르게 설정해야 했습니다. 즉, 사용자의 OU에 따라 사용자 유형이 결정되었습니다.
다음 단계는 학구 구성원 자격 및 사용자 유형을 기준으로 올바른 서버의 올바른 저장소에 사용자의 사서함을 만드는 것이었습니다. Outlook 캐시 모드가 올바르게 작동할 수 있도록 이 작업은 서비스 수준, 사서함 크기 제한 및 오프라인 주소록의 주소 목록에 영향을 주게 되었습니다. 확장 특성은 사용자가 적절한 주소 목록에만 나타나도록 학구 구성원 자격과 사용자 유형을 기준으로 설정되었습니다.
마지막으로 계정 특성이나 그룹 구성원 자격이 잘못 구성되거나 적절하지 않은 값으로 변경된 경우 이를 자동으로 수정하는 방법을 제공해야 했습니다. 사용자가 학구 도메인 내의 한 OU에서 다른 OU로 이동하면 이는 사용자 유형이 변경된 것이므로 사서함 위치, GAL 선택 및 주소 목록 표시 여부가 업데이트되어야 합니다.
이 문제를 해결하기 위해서는 이러한 작업을 수행하고 Active Directory의 일관성과 정확성을 보장해 주는 프로비저닝 시스템이 필요했습니다. 이에 따라 학구의 Exchange 2003 서버에서 정기적으로 실행되는 콘솔 기반 Visual Basic 응용 프로그램을 만들게 되었습니다. 정책 및 표준의 준수 여부를 확인하고 새로운 개체의 생성과 제공을 처리하는 이 응용 프로그램은 178개 학구 모두에 배포되었습니다.
수행해야 하는 작업은 일련의 스크립트로 신속하고 안정적으로 실행하기에는 지나치게 복잡했습니다. 그 결과 Visual Basic 기반 응용 프로그램이 적절한 솔루션이 될 것으로 보였습니다. Visual Basic 기반 응용 프로그램은 효율적이며 구조화된 오류 및 예외 처리를 지원하고 추후에 MIIS(Microsoft Identity Integration Server) 확장 코드에 맞게 응용 프로그램 내부 코드를 쉽게 수정할 수 있어서 코드를 다시 작성하는 작업이 최소화되기 때문이었습니다.
또한 새로운 조직으로 마이그레이션하는 중이었으므로 과거와 현재의 조직이 공존할 수 있는 방법을 찾아내야 했습니다. 새로운 환경에서 지원해야 할 레거시 SMTP 도메인이 178개가 넘었으며 일부 학구는 기존의 학생 전자 메일 도메인을 갖추고 있는 반면 다른 학구는 그렇지 않았습니다. 하지만 모든 학구를 한 번에 마이그레이션할 수 있었으며 일부 학구의 기존 메시지와 주소를 다른 학구에는 아무런 영향도 주지 않고 새로운 시스템으로 가져올 수 있었습니다. 하지만 Exchange 5.5에서 Exchange 2003으로 학구가 마이그레이션되었으므로 원활하지 않은 전자 메일 흐름이 발생하지 않도록 해야 했으며 이는 Exchange 2003 Active Directory와 레거시 Exchange 5.5 디렉터리 간에 일종의 디렉터리 동기화를 구현해야 함을 의미했습니다. Microsoft는 켄터키 교육부가 마이그레이션 기간 동안에만 MIIS를 사용할 수 있도록 허가해 주었고 이에 따라 사용자 지정 확장 코드를 개발하여 마이그레이션 전후 및 마이그레이션 기간 동안 MIIS를 통해 두 Exchange 조직을 동기화하는 데 사용했습니다.
새로운 Exchange 조직으로 이동하면 당연히 MAPI 클라이언트 구성에 영향을 주게 됩니다. 켄터키 교육부는 마이그레이션 기간 동안 다시 구성해야 할 학구 수준 MAPI 프로필이 수만 개가 넘는다는 사실에 직면하게 되었습니다. 다행히 당시 Microsoft에서 Exchange 프로필 도구(ExProfRe.exe)를 출시하게 되어 학구의 프로필을 마이그레이션하는 데 사용할 수 있었습니다. 이때 미리 로드된 값으로 ExProfRe.exe를 실행하는 패키지된 설치 관리자를 만들어 학구 수준 프로필 마이그레이션을 자동화된 방식으로 수행할 수 있게 하였습니다. 이 프로그램은 그룹 정책을 통해 호출되었으며 두 조직 간의 자동화된 프로필 마이그레이션의 성공률이 거의 100%에 이른다는 것을 확인할 수 있었습니다.

하드웨어 업그레이드
새로운 Exchange 2003 서버가 지리적으로 분산된 Exchange 5.5 서버를 대체하게 될 것이므로 이 솔루션의 하드웨어 측면에서는 Exchange 5.5 배포에서 지원한 사용자 수에 더해 학생 계정이라는 추가적인 로드를 지원해야 했습니다. 모든 학구 간 트래픽(인터넷 및 내부)은 전용 T1 회선(일부 학구의 경우 다중 T1 회선)을 통해 이동하도록 WAN 토폴로지가 설계되어 있으므로 서버는 학구 내에서 로컬로 호스팅되어야 했습니다.
예산, 관리 및 장비 호스팅 등의 제약으로 인해 Exchange 서버에 SAN(저장소 영역 네트워크) 연결 저장소가 없으므로 모든 저장소가 내부에 있거나 직접 연결되어 있어야 했습니다. 대부분의 학구에는 랙 저장소와 중앙 냉각 장치가 있는 데이터 센터가 없었으므로 서버는 가능한 한 독립적이어야 했습니다. 다행히 대부분의 학구는 사용자 수가 5,000명 미만이어서 단일 서버 배포가 가능했습니다. 이보다 사용자 수가 많은 학구는 보다 강력한 서버(또는 다중 서버)와 추가 저장소를 사용했으며 때로는 별도의 프런트 엔드 서버를 두어 학생과 직원의 트래픽을 추가로 분리했습니다.
대부분의 학구에는 최대한의 15,000RPM Ultra320 SCSI 드라이브와 여러 개의 RAID 컨트롤러, 그리고 4GB의 RAM으로 구성된 듀얼 프로세서 서버를 배포할 수 있었습니다. 이보다 규모가 큰 학구는 필요한 경우 보다 작은 프런트 엔드 서버를 사용하여 한 대 이상의 4중 프로세서 서버를 배포했습니다. 배포 전에 수행한 벤치마킹 및 성능 테스트 결과 어떠한 사용성 문제나 로드 문제도 나타나지 않았습니다. 하지만 다양한 수준의 로컬 사용 패턴이 서버의 전반적인 성능을 결정하는 실질적인 요인이 될 것으로 예측되었습니다.

POC(개념 증명) 테스트
프로덕션 환경은 178개의 도메인으로 구성된 Active Directory 포리스트 하나로 이루어지지만 POC(개념 증명) 테스트 환경은 13개의 학구 도메인과 빈 루트 도메인 하나로 그 규모를 축소했습니다. 모든 테스트 도메인은 프로덕션 도메인에서 내보낸 데이터로 채웠습니다. 선택된 몇몇 학구의 데이터베이스 사본을 사용하여 가상 Exchange 5.5 서버를 구축하고 구성함으로써 계획된 환경을 조성하고 마이그레이션 프로세스를 테스트할 수 있었습니다. 전체 POC 테스트 환경은 가상 컴퓨터를 사용하여 구축함으로써 이 환경을 기준으로 만들고 확정한 다음 필요할 때 다시 배포할 수 있도록 했습니다.
스크립트(VBScript 사용), SMS(Systems Management Server) 설치 관리자 패키지 및 콘솔 응용 프로그램을 다양하게 조합해 본 후 이를 코드화하고 테스트하여 최종적인 것으로 확정 지었습니다. 그 결과 받는 사람 정책, GAL 및 사용자 지정 주소 목록, 사용 권한을 비롯하여 Exchange 2003 초기 설정 및 구성 작업을 수행하는 스크립트들이 만들어졌습니다. 이러한 마이그레이션 스크립트로 관리 그룹 구성, 학구 도메인 구성(보안 그룹 생성 및 사용 권한 위임), 배포 후 구성 작업도 처리하였습니다.
하지만 Exchange 2003 서버를 준비하는 동안 몇 가지 중대한 과제에 직면하게 되었습니다. 마이그레이션의 나머지 단계를 위태롭게 만들지 않으면서 모든 178개 도메인에 Exchange 서버를 성공적으로 설치해야 했습니다. Exchange 2003은 도메인의 첫 번째 Exchange 2003 서버가 설치되기 전까지는 도메인의 Exchange Domain Servers 그룹이 조직의 ACL에 추가되지 않는다는 점에서, DomainPrep 프로세스를 실행할 때 이 그룹이 추가되는 Exchange 2000과 다릅니다. 따라서 필요한 모든 보안 그룹이 Active Directory의 조직 개체에 나열되도록 하기 위해 지정된 도메인을 설치하고 이 도메인에서 Active Directory 복제 허브 사이트로 Active Directory를 수동으로 복제한 후 Exchange 2003 서버를 설치할 다음 학구로 해당 복제본을 가져와야 했습니다. 조직 개체의 ACL에 이전 학구의 Exchange Domain Servers 그룹이 있는지 확인한 후에만 다음 학구에서 Exchange 2003 서버 설치를 안전하게 시작할 수 있었습니다. 한 도메인에서라도 이 프로세스가 순서에 맞지 않게 완료될 경우 해당 학구는 적어도 설치 작업을 다시 수행해야 하는 어려움을 겪거나 다른 학구에서 다른 모든 학구가 올바르게 나열되지 않는 조직 개체 ACL로 인해 학구 간 커뮤니케이션을 수행할 수 없게 되었습니다.
우리는 POC 환경 내에서 이 프로세스가 올바르게 작동한다는 것을 충분히 확인할 수 있을 때까지 전체 배포, 구성, 서버 준비, 마이그레이션을 여러 번 테스트했습니다.

마이그레이션 및 늘어나는 작업
프로젝트 팀으로부터 POC 프로세스와 그 결과를 승인받음에 따라 마이그레이션을 시작할 준비가 완료되었습니다. OET는 먼저 OET부터 마이그레이션을 시작하여 그 프로세스와 효과를 경험해 보기로 했습니다. 마이그레이션을 수행할 시점에는 모든 서버의 준비가 완료되었고 초기 환경도 검증을 마쳤습니다. 프런트 엔드 프로토콜 서버와 사서함 서버도 모두 배치되어 프로덕션 환경에서 사용자가 사용할 수 있도록 준비를 마쳤습니다.
마이그레이션 계획은 순조롭게 실행되었고 한 서버에서 다른 서버로 콘텐츠를 전송하는 기나긴 21시간이 지난 후 Exchange 2003에서 OET 시스템이 작동하기 시작했습니다. 다행히 Exchange 5.5에서 Exchange 2003으로 Outlook 프로필을 마이그레이션하는 동안 별다른 문제가 발생하지 않았습니다. 우리는 ExProfRe.exe를 호출한 배치 파일을 몇몇 단순한 논리를 기반으로 하여 다양한 구성으로 패키징했습니다. 그런 다음 배치 파일과 ExProfRe.exe를 각 학구의 DC(도메인 컨트롤러) Netlogon 공유에 배포하고 마이그레이션이 끝날 때 그룹 정책을 사용하여 모든 클라이언트에 대해 배치 파일을 실행했습니다. OET에서 이 과정이 올바르게 수행되었으므로 프로세스가 순조롭게 진행될 것이라는 것을 확신할 수 있었습니다.
이때 OET 배포를 통해 얻은 경험을 바탕으로 마이그레이션 계획을 검토하고 재차 승인을 받았습니다. 마이그레이션을 진행하면서 첫 번째 프로덕션 사이트로 6개의 학구를 선택했습니다. 각 학구를 마이그레이션하기 전에 MIIS에서는 Exchange 5.5에서 학구 사서함에 대한 최신 정보를 읽고 학구 도메인의 해당 사용자를 업데이트했습니다. 실제로 조직 간에 사서함 데이터를 이동하는 데는 Exchange 마이그레이션 마법사(Mailmig.exe)를 사용했습니다. 이 마법사는 사서함 데이터를 이동할 때 원래 MIIS에서 Active Directory로 내보낸 데이터에서 모든 프록시 주소를 가져와 업데이트합니다. 메일은 마이그레이션이 진행되는 동안 프런트 엔드 SMTP 서버의 큐에 놓이고 마이그레이션, 마이그레이션 후 서버 구성과 사용자 테스트가 끝난 후에 학구로 보내졌습니다. 학구는 ExProfRe.exe를 사용하여 대규모 클라이언트 마이그레이션을 수행할 준비가 되었습니다.

RUS 관련 문제 극복
Outlook 클라이언트가 올바르게 작동하려면 프로비저닝 솔루션이 특성 값을 설정하는 데 있어서 최종적인 권한을 가지도록 해야 했습니다. 또한 RUS(받는 사람 업데이트 서비스)가 계정 설정 시 이 작업을 마치도록 해야 했지만 RUS는 프로비저닝이 끝난 후에만 실행되어야 합니다. 이 두 가지 목적을 달성하기 위해 178개 학구 모두의 RUS 인스턴스 일정을 "Never"(업데이트 안 함)로 설정하고 프로비저닝이 완료된 후에 시작되도록 RUS를 트리거하는 코드를 프로비저닝 솔루션에 포함했습니다.
대부분의 학구는 사용자 수가 5,000명 미만이었고 매일 수행되는 업데이트 횟수는 이보다 훨씬 적었습니다. 프로비저닝 시스템은 매일 실행이 끝날 때 다시 빌드되는 대신 업데이트를 시작했으므로 RUS가 신속하게 완료되었습니다. 하지만 사용자가 10,000명이 넘는 학구도 몇 곳 있었습니다. 이러한 대규모 환경에서는 업데이트를 수행하는 데 보다 많은 시간이 소요되었으며 대규모 도메인에서 RUS를 다시 빌드해야 할 경우 이를 실행하는 데 일주일 이상이 걸릴 수도 있었습니다. RUS는 실행될 때 모든 개체 유형을 평가하므로 대규모 도메인에서 RUS를 다시 빌드하는 것은 시간과 노력이 많이 드는 일이었습니다.
이 문제를 해결하기 위해 Exchange 제품 그룹의 구성원들과 협력했지만 마땅한 마이그레이션 전략을 찾아내지 못했습니다. 대신 RUS가 일반적으로 수행하는 작업의 많은 부분을 처리하도록 프로비저닝 코드를 개선했습니다. 초기 프로비저닝이 시작될 때 showInAddressBook과 proxyAddresses 특성이 이미 채워져 있도록 설정되었으므로 사용자는 RUS의 작업이 완료될 때까지 기다리지 않고 곧바로 로그인할 수 있습니다. 이 외에도 정기적으로 LDIFDE를 가져오고 RUS gatewayProxy 주소를 정리함으로써 받는 사람 정책이 환경에 실수로 적용되었더라도 조직 내 모든 RUS의 할 일 목록에 들어가지 않도록 하는 수동 작업을 만들어 프런트 엔드 Exchange 2003 프로토콜 서버 중 하나에서 실행되도록 했습니다.

분류기 문제
학생 신상 데이터가 학구 외부로 새어 나가지 않게 하는 것과 맥락을 함께 하는 것이 바로 학생이 소속 학구 외부의 사용자 또는 시스템 외부의 인터넷 주소로 전자 메일을 보낼 수 없도록 제어하는 기능을 구현하는 것입니다. 이를 위해 커넥터 및 관련 항목들로 구성된 정교한 시스템을 만드는 대신 Exchange 2003의 잘 알려지지 않은 기능을 구현하기로 결정했으며 이에 따라 학구의 기존 라우팅 그룹 커넥터에 대한 커넥터 제한을 프런트 엔드 프로토콜 서버가 있는 중앙 허브에 적용했습니다. 각 도메인에 직원용과 학생용으로 각각 하나씩 두 개의 보안 그룹을 만들었으며 이 두 그룹을 커넥터 제한에 추가했습니다.
하지만 레지스트리에 커넥터 제한 검사를 설정한 후 매우 중대한 몇 가지 성능 저하 문제가 발견되기 시작했습니다. 메시지가 분류기와 로컬 배달 큐에 여러 시간 동안 정체되었으며 이는 동일한 서버의 받는 사람에게로 가는 메시지의 경우에도 마찬가지였습니다. 이 문제는 다른 학구가 차츰 마이그레이션됨에 따라 더욱 악화되었습니다. 임시 해결책으로 커넥터 제한 검사 기능을 해제했고 그 결과 메일 배달 성능이 개선되었습니다. 그 후 문제를 좀 더 면밀하게 조사한 결과 메시지가 전송될 때 분류기가 자체 도메인 내의 두 그룹뿐만 아니라 나머지 177개 도메인에 있는 동일한 두 그룹에 대해서도 그룹 구성원 자격을 검사하고 있음이 드러났습니다. 이 작업은 서버로 들어오거나 서버에서 나가는 모든 메시지에 대해 수행되었습니다.
이후 Microsoft에 이 문제에 대한 지원을 요청했습니다. 이 문제에 대한 평가를 마친 후 현재 Microsoft는 토폴로지 복잡도가 감소된 모드에서 분류기를 실행할 수 있도록 하고 있으며 이 문제를 해결하기 위한 핫픽스를 개발 중입니다. 핫픽스에 대한 자세한 내용은 아직 알 수 없지만 핫픽스 개발 목적은 분류기가 라우팅 토폴로지에 대해 특정 상황을 가정하도록 만들어 모든 커넥터에서 그룹 구성원 자격을 검사하지 않도록 하는 설정을 제공하는 것입니다.

교훈
이 프로젝트에서 얻은 교훈이 한 가지 있다면 비즈니스 요구 사항이야말로 컨설턴트가 수행하는 모든 작업을 결정하는 요소라는 것입니다. 컨설팅을 하다 보면 비즈니스 요구 사항의 실현 가능성과 솔루션의 복잡함 중에서 어느 것에 무게를 두어야 할지를 결정해야 할 때가 많습니다. 이 칼럼에서 제가 제안한 결정과 선택은 시간이 부족해서 여기에서는 다루지 못한 여러 가지 요소를 포함하여 주어진 환경, 리소스, 그리고 비즈니스 요구 사항에 가장 적합하다고 판단한 것이었습니다. 물론 독자 여러분은 다른 결정을 내릴 수도 있습니다. 하지만 이 칼럼에서 제가 제시한 아이디어가 도움이 되는 것이기를 바랍니다. 다행히 Exchange 2003과 Active Directory는 이 복잡한 마이그레이션의 모든 요구 사항을 충족하기에 충분할 정도로 융통성이 뛰어났습니다. 켄터키 교육부 배포 프로젝트의 엄청난 규모를 알고 나면 실제 솔루션은 오히려 단순하다고 느낄 것입니다. 또한 솔루션이 Active Directory 및 Exchange 2003의 충분히 활용되고 있지 않은 기능을 기반으로 구축되었다는 사실도 알 수 있을 것입니다.
두 번째 귀중한 교훈은 문제 해결 및 위험/문제 관리에 대해 균형 잡힌 접근 방법을 취해야 한다는 것입니다. 자체적으로 문제를 해결하는 것이 적절할 때도 있고 Microsoft 기술 지원 서비스의 고급 리소스로부터 도움을 요청하는 것이 필요할 때도 있습니다.

향후 예상
켄터키 교육부의 환경은 분명히 고유한 것입니다. 이 솔루션을 배포하는 과정에서 Exchange의 거의 모든 기능이 바로 사용되거나 교육부의 요구 사항에 맞게 수정되었습니다. 이제 전체 환경이 성공적으로 배포되고 마이그레이션되었으므로 추가 기능을 구현할 수 있는 준비가 되었습니다. 켄터키 교육부는 이미 Windows Mobile® 플랫폼에 대한 학구의 관심을 알고 있으며 모바일 장치로의 이동이 계속될 것으로 예상하고 있습니다.
서버 통합을 통해서도 많은 혜택을 얻을 수 있습니다. 현재 켄터키 교육부는 Active Directory 환경의 몇 가지 측면을 가상화하는 문제를 검토하고 있습니다. 또한 Exchange 2007이 곧 출시될 것이라는 전망과 함께 켄터키 교육부는 자체 메시징 시스템의 업그레이드 요구 사항을 검토하기 시작했습니다.
이 외에 켄터키 교육부는 Live Communication Server, Live Meeting Server 등에서 제공하는 공동 작업 기능도 검토하고 있습니다. Microsoft Operations Manager 2005도 현재 Exchange 및 Active Directory 서버에 대한 관리와 모니터링을 위해 배포 중에 있습니다.

결과
제 자녀와 이 프로젝트에서 함께 작업한 동료들의 자녀를 비롯하여 켄터키 주 공립 학교에 재학 중인 모든 어린이들은 구현된 솔루션의 품질과 보급에 따른 영향을 크게 받을 것입니다. 이 솔루션 구현은 켄터키 교육부가 이전보다 안전하고 표준화된 방식으로 선진 기술을 발 빠르게 활용할 수 있는 입지를 마련해 주었습니다. 필자는 개인적으로 이 프로젝트에 참여한 것을 매우 자랑스럽게 생각합니다.

Whitney Roberts는 KiZAN Technologies(www.kizan.com)의 수석 컨설턴트로, Exchange 4.0이 출시된 이후로 Exchange 작업을 담당해 왔습니다.


 SQL Q+A: 재부팅 방지, 여러 업데이트 설치 및 기타 질문
SQL Q+A
재부팅 방지, 여러 업데이트 설치 및 기타 질문
Nancy Michell 편집

재부팅 방지

Q: 핫픽스 등을 SQL Server 및 서버 운영 체제에 일반적으로 적용할 때 재부팅 횟수를 제한할 수 있는 방법이 있습니까?

A: 먼저, 설치 후 발생하는 재부팅은 대부분의 경우 설치 프로그램에 하드 코드되어 있지 않다는 점을 알아 두는 것이 좋습니다. 재부팅은 대개 파일이 잠겨 있기 때문에 발생합니다. 즉, 다른 응용 프로그램이나 운영 체제에서 현재 사용하고 있는(잠겨 있는) 파일을 설치 프로그램에서 업데이트하려고 하기 때문에 발생합니다. 따라서 이러한 재부팅을 막는 간단한 방법은 문제가 되는 파일을 사용 중인 프로세스가 없도록 하는 것입니다. 그러기 위해선 어떻게 해야 할까요?
첫 단계는, 설치 중에 사용 중이거나 잠겨 있는 파일을 파악하는 것입니다. 가장 쉬운 방법은 HKLM\system\currentcontrolset\control\sessionmanager\pendingfilerenameoperations의 레지스트리에서 찾아보는 것입니다. 이 레지스트리 키를 검사하는 목적은 두 가지입니다. 하나는 재부팅 요청이 정말로 잠긴 파일에 의해 발생한 것인지 확인하는 것이고 또 하나는 잠겨 있는 파일이 무엇인지 확인하는 것입니다. 설치 후 다시 부팅하기 전에 이 레지스트리 키를 조회해 보면 재부팅 요구가 발생한 원인을 알 수 있으며, 이후의 다른 설치 작업에서 재부팅이 발생하지 않도록 조치를 취할 수 있습니다.
이 레지스트리 키에는 두 가지 유형의 항목이 있습니다. 파일이 읽기 작업으로 잠긴 경우 파일당 한 줄로 항목이 표시되는데, 이는 업데이트된 파일이 이미 디스크에 있지만 아직까지 사용 중인 임시 복사본을 제거해야 함을 나타냅니다. 파일이 쓰기 작업으로 잠긴 경우 파일당 두 줄로 항목이 표시되며, 이는 업데이트가 아직 발생하지 않았고 응용 프로그램의 상태를 알 수 없기 때문에 해당 파일을 사용해서는 안 된다는 것을 나타냅니다. 말 그대로 설치 중에 중지된 경우입니다. 이 경우 한 줄은 실제 파일을 나타내고 다른 줄은 재부팅 중에 실제 파일이 될 임시 파일을 가리킵니다.
다음 단계는 여러 요인에 따라 달라질 수 있지만, 기본적인 아이디어는 잠긴 파일을 사용하고 있는 소프트웨어를 식별하는 것입니다. 종속성 검사기(가능한 경우)나 MSDN®의 DLL HELP 데이터베이스(support.microsoft.com/kb/815065(영문) 참조)를 사용하십시오.
확인한 소프트웨어에 서비스가 있으면 해당 서비스를 수동으로 중지한 다음 다시 테스트합니다. 응용 프로그램인 경우에는 응용 프로그램을 닫고 다시 시도합니다. 여러 응용 프로그램에서 단일 파일을 사용하고 있는 경우에는 해당 응용 프로그램을 모두 종료해야 합니다.
이러한 테스트를 테스트 환경에서 수행하면 프로덕션 환경에서 중지해야 하는 응용 프로그램 및 서비스 목록을 설치 전에 얻을 수 있습니다. 이 목록을 활용하면 어떠한 소프트웨어도 설치 프로그램에서 설치하는 파일을 잠그지 않게 되므로 프로덕션 환경에서 재부팅이 발생하지 않게 됩니다. 물론 설치가 완료된 후에는 각 응용 프로그램을 다시 시작해야 합니다.
이와 관련하여 한 가지 반가운 점은 잠금은 거의 변경되지 않으므로 일단 사용자 시스템의 패턴을 파악하고 나면 시스템을 사용하는 동안 내내 수많은 재부팅을 방지할 가능성이 큽니다.
알려 드리고 싶은 유용한 방법이 하나 더 있습니다. 여러 버전의 SQL Server™나 다른 제품이 함께 설치되어 있을 수 있으며, 심지어 설치된 제품의 버전 레벨이 서로 다를 수 있습니다. 이런 경우에는 항상 최신 버전을 먼저 업데이트해야 합니다. 이렇게 하면 업데이트로 인해 최신 버전의 모든 요소가 교체되기 때문에 그 외의 다른 인스턴스에서는 잠금을 신경 쓰지 않아도 될 확률이 큽니다. 예를 들어 세 개의 SQL Server 2000 SP3 인스턴스가 있는 경우 SP4로 업그레이드하는 첫 번째 인스턴스는 MSXML3.dll 파일을 업그레이드하고 재부팅을 수행해야 합니다. 만약 지금 재부팅을 수행했다면, 다음 두 인스턴스를 SP4로 업그레이드할 때는 업데이트된 MSXML3.dll 파일이 이미 존재하기 때문에 다시 부팅할 필요가 없습니다. 이는 SQL Server 2005 인스턴스를 업그레이드한 후 SQL Server 2000 인스턴스를 업그레이드하는 경우나 SQL Server 2000 인스턴스를 업그레이드한 후 SQL Server 7.0 인스턴스를 업그레이드하는 경우에도 마찬가지입니다. 이 방법은 실제로 효과가 있는 일반적인 재부팅 최소화 전략입니다.
뒤돌아 보면, Microsoft 개발 팀은 다양한 시나리오에서 재부팅 횟수를 줄이거나 없애기 위해 많은 노력을 기울여 왔습니다. 이 칼럼은 SQL Q&A 칼럼이므로 SQL Server를 예로 들겠습니다.
SQL Server 2005의 경우 SQL Server 팀은 Microsoft® Data Access Components(MDAC) 자체를 업데이트하지 않고 SQL Server에 필요한 MDAC 코드를 SQLNCLI(새 파일)로 분리하고, MDAC를 OS와 인밴드(in-band)된 상태로 되돌려 놓았습니다. 이 방법의 장점은 무엇일까요? Windows® 운영 체제는 자체적으로 MDAC를 사용하기 때문에 이들 파일을 잠긴 상태로 유지합니다. 바로 이 이유 때문에 대부분의 SQL Server 서비스 팩 및 기타 패키지에서 재부팅이 발생하는 것입니다. 하지만 이제는 SQL Server에서 OS의 사용 중인 MDAC 파일을 건드리지 않고 MDAC 버전을 업데이트할 수 있기 때문에, 재부팅이 필요 없어졌습니다.
또한 SQL Server 2005 SP1 설치 프로그램은 이제 종속성 검사기와 일시 중지 기능을 기본적으로 제공합니다. 이 기능을 사용하면 잠겨 있는 파일과 이 파일을 잠근 프로그램을 확인하고 바로 그 곳에서 파일을 잠근 응용 프로그램을 중지할 수 있으므로 재부팅 없이 설치 작업을 계속할 수 있습니다. 즉, 실시간으로 이 기능을 사용할 수 있기 때문에 테스트 환경이 필요하지 않습니다. 물론, 항상 계속해서 진행하다가 원할 경우 또는 무인 모드로 실행 중인 경우 재부팅을 수행할 수 있습니다. 이 기능을 사용하면 파일을 잠근 응용 프로그램을 파악하기가 무척 쉽다는 것을 알 수 있습니다.
또한 Microsoft Installer 기술은 기존 PFR(PendingFileRenameOperations)도 더욱 효과적으로 처리합니다. SQL Server 2000 설치 프로그램은 앞에서 설명한 레지스트리 키에 파일이 있는 경우 중단된다는 점을 기억하고 있을 것입니다. SQL Server 2005 설치 프로그램은 상당히 지능적이어서 해당 파일이 SQL Server에 속한 파일인 경우(충돌이 발생할 가능성이 있음을 나타냄)에만 중단되며, 이 경우에도 대개는 PFR 키에 접근하여 재부팅 없이 해당 키를 직접 업데이트할 수 있습니다. 이 기술의 일부는 모든 업데이트 수행에 사용되는 현재의 표준 Microsoft 설치 관리자인 MSI와 update.exe에 포함되어 있습니다.
현재 재부팅을 일으키는 것으로 알려진 파일로는 어떤 파일들이 있을까요? 가장 중요한 파일 중 하나는 MSXML3.dll입니다. 이 파일은 항상 Windows SVCHost 서비스에 의해 잠기므로 이 서비스를 포함하는 모든 프로그램은 다시 부팅해야 합니다. MDAC 스택(mdac_typ.exe) 역시 재부팅을 유발하는 주요 원인입니다. 다행히 MDAC는 Windows Server® 2003 및 Windows XP SP2 이상에서 "인밴드"되어 있습니다. SQL Server 개발 팀에서 SQL Server 업데이트로 인해 재부팅이 발생하지 않도록 msxmlsql.dll을 분리해 내는 훌륭한 성과를 이룩했지만 아직까지는 가끔씩 재부팅이 발생할 수도 있습니다. 이 경우 사용자가 할 수 있는 일은 없습니다. 즉, SVCHost를 종료하고 업데이트를 계속 실행할 수 있는 방법은 없습니다.
또한 update.exe 패키지의 제거 프로세스에 약간의 문제가 있습니다. 응용 프로그램을 제거할 경우 설치 관리자의 현재 위치에서 파일이 잠깁니다(물론 PFR 키의 파일은 아님). 이렇게 되면 재부팅을 통해 해당 잠금이 풀릴 때까지 다른 update.exe 패키지가 실행되지 않습니다. 이런 상황에서 실제로 할 수 있는 일이라고는 이 문제를 인식하고 핫픽스 제거 후 재부팅할 계획을 세우는 것뿐입니다.
간헐성 또한 문제입니다. 모든 프로그램이 파일을 일정 시간 내내 사용하는 것은 아닙니다. 실제로 공유 DLL 대부분은 특정 시점에만 사용됩니다. 즉, 공유 DLL은 다른 프로그램에서 프로그램의 작업과 코드 경로에 따라 필요한 경우에만 액세스됩니다. 다시 말해서 10번을 테스트해서 잠겨 있는 파일이 없었다고 해도, 프로덕션 배포 시점에는 잠겨 있는 파일이 있을 수 있습니다. 안타깝게도 이 문제를 해결할 수 있는 방법은 아직 없습니다. 프로덕션 환경과 되도록 동일하게 테스트 환경을 구축하고(작업 부하까지도 고려) 충분한 테스트를 수행하여 이러한 문제를 테스트 과정에서 발견해 내는 것만이 최선의 방법입니다.
OS 서비스 팩을 설치하거나 업그레이드하면 재부팅이 필요합니다. 또한 Windows 2000, Windows XP 및 그 이전 버전인 경우 pendingfilerenameoperations 레지스트리 키가 비어 있더라도 재부팅을 해야만 설치가 완료됩니다. 재부팅 중에 코드를 설치하기 위해 실행될 수 있는 예외 패키지 등록 작업이 있습니다. 이러한 작업은 서비스 팩 설치 과정의 일부는 아니지만, 사용 중인 특정 코드를 존속시키기 위해 업그레이드 시나리오에 의해 실행된, 현재 운영 체제에 포함된 명령입니다.
마지막으로 PFR 키는 파일 버전을 검사하지 않으며 직렬화를 통해 정렬을 강제로 수행하지도 않습니다. 즉, 파일의 나열 순서에 따라 파일 교체가 이루어집니다. 그러나 하드 디스크에 적용되는 순서는 마지막 파일이 완료되는 시점(첫 번째 파일이 시작되는 시점이 아님)으로 확인되었습니다. 이는 납득할 만한 시나리오지만, 만약 같은 경로에 같은 파일에 대한 두 개의 복사본이 있고 각 복사본이 다른 버전을 가리킨다면 재부팅 후의 결과를 예측하기가 어렵습니다. 따라서 이런 경우가 발생하면 올바로 수정되었는지 확인해야 합니다. 확실하지 않은 경우에는 재부팅 후에 두 설치 프로그램을 다시 실행하여 확인합니다. 올바른 파일이 설치되었으면 추가 작업은 필요하지 않습니다. 잘못된 파일이 설치된 경우에는 올바른 파일을 갖고 있는 패키지가 문제를 해결하게 됩니다. 솔직히, 이 방법이 원하는 결과를 파악하려고 시도하는 것보다 더 빠르고 안전합니다.

서비스 팩을 여러 번 설치

Q: 4 노드 클러스터에 SQL Server 2000의 클러스터형 인스턴스 8개가 있는데 최소한의 재부팅으로 SP4를 설치하고 싶습니다. 8개의 인스턴스에 차례로 SP4를 설치한 다음 마지막에 모든 노드를 재부팅할 수 있는 방법이 있습니까?

A: 클러스터형인지에 관계없이 일단 지정된 Windows 서버에 하나의 SQL Server SP4 인스턴스를 완전히 설치했다면(이때는 재부팅 필요) 같은 시스템에 있는 다른 SQL Server 인스턴스에 SQL Server SP4를 설치해도 재부팅이 발생하지 않아야 합니다. 그 이유는 모든 공유 파일(도구, MDAC, MSXML 등)이 이미 올바른 버전이므로 잠금 여부에 상관없이 추가 업데이트가 필요하지 않기 때문입니다. 모든 비공유 파일은 첫 번째 인스턴스에서만 사용되며 설치 프로그램에 의해 종료됩니다. 여러 버전의 여러 인스턴스가 존재하는 경우에는 SQL Server 의 최신 인스턴스를 가장 먼저 업데이트해야 한다는 점을 기억해 두는 것이 좋습니다.

네트워크 서비스로 실행

Q: NT AUTHORITY\NETWORK SERVICE 계정은 무엇이며 이 계정의 기본 용도는 무엇입니까? 또한 보안적인 면에서 이 계정은 어떤 의미가 있으며, 특히 sysadmin(sa) 권한이 이 계정에 부여되었다면 특별한 의미가 있는 것입니까?

A: 네트워크 서비스 계정은 네트워크에서 시스템과 동일한 ID(컴퓨터 ID)를 갖지만 로컬 시스템에 대한 권한은 제한되어 있습니다. 따라서 네트워크 리소스에 액세스해야 하는 서비스의 경우 아마도 도메인 컨트롤러를 사용하여 계정 이름을 확인하기 위해, 시스템(도메인 계정) 또는 네트워크 서비스로 실행되어야 합니다. 이 경우 네트워크 서비스는 그 범위가 로컬 시스템으로만 제한되고 해당 범위 내에서도 축소된 권한만을 가지므로 이를 선택하는 것이 일반적으로 가장 안전합니다.
SQL Server에서 네트워크 서비스에 sysadmin 권한을 부여한다는 것은 로컬 시스템에서 네트워크 서비스로 실행되는 다른 모든 서비스가 서버에 대해 모든 권한을 갖게 된다는 것을 의미합니다. 예를 들어 SQL Server 서비스 계정이 네트워크 서비스로 실행되도록 구성된 경우 이런 상황이 발생합니다. SQL Server 서비스 계정을 sysadmin의 구성원으로 만들려면 서버 기능이 필요합니다(예: 루프백 연결 허용). 네트워크 서비스를 SQL Server의 admin으로 실행하는 것이 보안상 그다지 좋은 방법은 아니지만, 같은 용도로 도메인 계정을 사용하는 것보다는 바람직할 가능성이 크며 SQL Server를 LocalSystem으로 실행하는 것보다는 훨씬 더 안전합니다.
네트워크 서비스에 sysadmin 권한을 부여하고 싶지 않을 경우 그 다음으로 선택할 수 있는 방법은 하나 이상의 Windows NT® 설치에서 SQL Server를 실행하도록 전적으로 특별히 지정된 도메인 계정을 사용하는 것입니다.
자세한 내용은 msdn.microsoft.com/library/en-us/dnpag2/html/paght000009.asp(영문) 및 microsoft.com/technet/security/topics/serversecurity/serviceaccount(영문)를 참조하십시오.

여러 데이터베이스 만들기

Q: 데이터를 개별 데이터베이스로 분할하여 최대 250개의 데이터베이스를 동시에 온라인으로 사용하려고 합니다. 이 중 20%만이 특정 시점에 활성 쿼리에 사용될 것으로 예상되는데, 데이터베이스가 많을수록 더 좋습니까?

A: 데이터베이스 서버 인스턴스 내의 데이터베이스 수는 비즈니스 요구과 관리 요인에 따라 결정해야 합니다. 단일 서버 인스턴스 내에 여러 데이터베이스를 만드는 데 들어가는 오버헤드는 거의 없지만, 데이터베이스가 많아지면 백업 및 복원, 미러링, 사용자 계정 및 사용자 역할 등의 유지 관리 작업을 위해 더 많은 관리 오버헤드가 필요합니다. 관리 작업이 복잡해진다는 바로 이 점이 추가된 데이터베이스의 장점보다 클 수 있습니다.
일반적으로 하나의 응용 프로그램과 관련된 모든 데이터는 하나의 데이터베이스에 저장해야 장애가 발생했을 때 복구하기가 쉽습니다. 응용 프로그램의 데이터가 여러 데이터베이스에 분산되어 있으면 장애 조치 중에 모든 데이터베이스를 복구해야 합니다. 이로 인해 복구가 지연될 수 있으며, 데이터베이스 중 하나가 복구하기 어려운 경우 심지어 복구 자체가 불가능할 수도 있습니다.
즉, 다음과 같이 타당한 이유가 있을 때만 데이터베이스를 여러 데이터베이스로 분리하는 것이 좋습니다.
  • 일부 데이터의 백업 요구 사항이 다른 데이터와 다른 경우
  • 특정 데이터에 별도의 보안 컨텍스트가 필요한 경우, 즉 데이터베이스 소유자가 다른 경우
  • 데이터의 용도가 기록용이어서 데이터를 읽기 전용 모드로 유지해야 하는 경우

기술적 자문을 주신 Microsoft IT 전문가: Ramon Arjona, Frank De Waelle, Robert Djabarov, Herman Learmond-Criqui, Maxwell Myrick, Ruslan Ovechkin, Uttam Parui, Shashi Ramaka, Gary Roos, Gavin Sharpe, Vijay Sirohi, Jimmie Thompson 및 Madhusudhanan Vadlamaani

Nancy Michell 편집


 Hey, Scripting Guy!: 컵 홀더는 어디 있을까요?
Hey, Scripting Guy!
컵 홀더는 어디 있을까요?
Microsoft Scripting Guys
이 칼럼은 Windows PowerShell의 시험판 버전을 기준으로 작성되었습니다. 이 문서에 수록된 모든 정보는 변경될 수 있습니다.

새로운 기술이 소개된 후 사람들이 구기술과의 차이를 실제로 인식하기 위해서는 어느 정도의 시간이 필요합니다. 최초의 자동차를 생각해 보세요. 이 기묘한 기계는 말이 끄는 마차와 같은 일을 했기 때문에 말 없는 마차라고 불렸습니다. 생각해 보면 최초의 자동차와 마차의 차이점은 마차에는 말이 필요하고 자동차에는 말이 필요 없다는 것뿐입니다. 그것을 제외하면 그 둘을 구별하기란 매우 어렵지요.
물론 오늘날에 자동차와 말이 끄는 마차를 혼동하는 사람은 없습니다. 그것은 바로 오랜 세월 동안 자동차를 만든 사람들의 노력의 결과로 자동차와 마차가 명확하게 구분되었기 때문입니다. 오늘날 자동차는 CD 플레이어, 에어컨, 위성 네비게이션 시스템 등이 완비된 상태로 공장에서 직접 출하되지만 말이 끄는 마차는 그렇지 않습니다. 1880년대에 말이 끄는 마차를 몰고 있을 때 잠깐 동안 프라푸치노를 놓아 두어야 하는 상황이 발생했다고 생각해 보세요. 무척 난감했을 테지요? 그렇지만 요새 SUV에는 기본적으로 컵 홀더가 17개까지 마련되어 있고 운전자만을 위한 컵 홀더를 3개나 마련해 둔 자동차도 있습니다. 일부 신모델의 경우에는 필요에 따라 음료를 데우거나 차게 할 수 있는 컵 홀더도 있습니다.
참고 과거에 운전할 때는 세 가지 음료수를 마실 수 없었다는 것은 참으로 믿기 힘든 이야기네요. 한두 가지 음료수만을 마시면서 운전해야 했으니 정말로 힘들었겠지요?
신기술이 실질적인 성공을 거두려면 기존의 안정적인 기술보다 미지의 새로운 기술이 좋은 이유를 사람들이 알 수 있어야 합니다. DVD가 처음에 출시되었을 때 DVD는 비디오 레코더와 마찬가지로 집에서 영화를 보는 데 사용되었습니다. 그렇지만 DVD는 비디오 카세트에 비해 비쌌으며 DVD 플레이어에는 녹화 기능이 없었습니다. DVD가 선풍적인 인기를 끌지 못한 것은 당연한 결과일 테지요. 그렇지만 DVD 제조업체에서 삭제된 장면, 영화에서는 볼 수 없었던 배우들의 해설, 카세트 테이프에서는 얻을 수 없는 여러 가지 것들을 디스크에 포함하기 시작하면서 이전까지는 별로였던 DVD의 인기가 경쟁 기술인 VHS를 압도하기 시작했습니다. 집에서 영화를 볼 수 있다는 것만으로는 부족했기 때문에 DVD 제조업체에서는 사람들이 이미 가지고 있는 것을 넘어서는 무언가를 제공해야 했던 것입니다.
참고 사람들이 이러한 보너스 항목을 실제로 보았는지는 사실 중요하지 않습니다. 인간이란 존재는 무엇인가가 있으면 그것을 가져야 하기 때문이죠. 마침 Scripting Guy도 TechNet Magazine 칼럼에서 편집된 내용과 시스템 관리 스크립트에 대한 다른 결론으로 구성된 DVD 제작을 고려하고 있답니다.

Windows PowerShell 사용
이런 이야기는 Microsoft에서 출시한 새로운 명령 셸/스크립트 기술인 Windows PowerShell™에도 적용됩니다. Windows PowerShell을 처음 접할 때 사람들은 대개 이런 이야기를 듣게 됩니다.
  • "Windows PowerShell을 사용하면 프로세스와 서비스를 관리할 수 있습니다."
  • "Windows PowerShell을 사용하면 이벤트 로그에서 이벤트를 검색할 수 있습니다."
  • "Windows PowerShell에서는 WMI를 사용하여 컴퓨터를 관리할 수 있습니다."
이 이야기에는 잘못된 내용이 하나도 없을 뿐만 아니라 이러한 작업은 모두 유용하고 중요합니다. 이 이야기의 단 한 가지 문제는 이미 VBScript 및 Windows Script Host를 사용해서 그러한 작업을 모두 수행할 수 있다는 점입니다. 이전 버전과의 호환성이 중요한데 VBScript에서 수행할 수 있는 작업을 Windows PowerShell에서 수행할 수 없다면 Windows PowerShell은 대단한 혁신이 아닐 것입니다. 영화를 재생할 수 없는 DVD 플레이어를 상상해 보십시오. 사실 상상할 필요도 없습니다. Scripting Guy 중 한 명이 그런 DVD 플레이어를 갖고 있으니까요.
또한 Windows PowerShell이 VBScript에서 수행할 수 있는 작업만을 수행할 수 있다면 이 신기술 때문에 처음부터 고생할 필요가 없을 것입니다. 그러나 분명한 점은 VBScript에는 컵 홀더가 없다는 것입니다. 또한 Windows PowerShell도 마찬가지입니다. 그렇다면 이 새로운 스크립트 기술에는 어떤 차별성이 있을까요?
솔직히 말해서 Windows PowerShell에는 특별한 차이점이 없습니다. 컵 홀더가 없기는 하지만 Windows PowerShell에는 VBScript에 없는 몇 가지 기능이 있습니다. "고장나지 않은 것은 고치려고 하지 말라."는 말처럼 프로세스와 서비스를 관리하는 작업만 필요한 경우에는 Windows PowerShell을 고려할 만한 특별한 이유가 없을 것입니다. Scripting Guy는 이 말을 "고치려고 하면 고장나므로 고치지 말라."라고 이해합니다. Windows PowerShell을 사용해서 VBScript에서 할 수 없는 작업을 할 수 있을 때 Windows PowerShell의 진정한 가치가 드러날 것입니다. 그 예로 파일에 마지막으로 쓴 시간 변경과 같은 작업이 있습니다.

마지막 쓴 시간 변경
방금 전 파일에 마지막으로 쓴 시간 변경에 대해 이야기했습니다. 빠르고 간편한 버전 제어 양식과 같은 다양한 이유로 스크립트 작성자들은 항상 파일에 마지막으로 쓴 시간(또는 만든 시간)을 변경할 수 있는 날이 오기를 고대하고 있습니다. 불행하게도 WMI(Windows Management Instrumentation)나 FileSystemObject에서는 이 기능을 제공하지 않으며, 이 같은 기술에서는 파일 날짜와 시간이 읽기 전용으로 설정되어 있습니다.
그러나 Windows PowerShell에서는 다음 명령을 실행하면 간단하게 파일의 마지막 쓴 시간을 현재 날짜 및 시간으로 변경할 수 있습니다.
$a = Get-Item c:\scripts\test.txt; $a.LastWriteTime = Date
이 명령의 작동 방법을 설명하기 전에 먼저 모든 분이 궁금해하실 "WMI로는 할 수 없는데 어떻게 Windows PowerShell로는 파일에 마지막으로 쓴 시간의 변경이 가능할까"라는 질문에 대한 답을 드리겠습니다. 이것은 Windows PowerShell과 관련된 일반적인 오해를 단적으로 드러내는 질문이기 때문에 먼저 이 질문에 대답한 후 시작하는 것이 좋을 것 같습니다. 많은 사람들은 Windows PowerShell을 단지 WMI를 사용하는 새로운 방법 정도로 생각합니다. 그렇습니다. Windows PowerShell을 사용해서 WMI 데이터에 액세스할 수 있다는 것도 분명한 사실이며, 우리가 cmdlet(네이티브 Windows PowerShell 명령)이 추가로 만들어지기를 기다리는 동안 대부분의 시스템 관리 스크립트는 계속해서 WMI에 의지하게 될 것입니다. 그러나 Windows PowerShell은 .NET Framework를 기반으로 하며 Windows PowerShell cmdlet은 WMI 개체보다는 .NET 개체를 주로 다룹니다. 이 점은 .NET Framework를 통해 사용할 수 있는 속성이 WMI를 통해 사용할 수 있는 속성과 반드시 일치하지는 않기 때문에 잘 기억해 두어야 합니다.
예를 들어 Get-Item cmdlet을 사용하여 파일에 바인딩하면 WMI CIM_Datafile 클래스 인스턴스를 가져오지 않고 .NET 개체를 가져옵니다. 이 점이 크게 문제가 될까요? 그렇습니다. .NET 개체의 파일 관리 관련 속성 및 메서드 집합은 WMI의 것과 아주 작은 부분이 다릅니다. 앞에서 본 것처럼 속성이 읽기 전용일 때와 읽기/쓰기일 때 차이가 있듯이 이러한 약간의 차이가 매우 중요한 의미를 가질 수 있습니다.
질문으로 돌아가서 Get-Item cmdlet이 .NET 개체를 반환한다는 것을 어떻게 알 수 있겠습니까? 이 경우, 그리고 대부분의 경우 지금 다루고 있는 개체의 유형을 가장 쉽게 확인할 수 있는 방법(또한 사용할 수 있는 속성과 메서드를 식별할 수 있는 가장 쉬운 방법)은 파일에 바인딩한 다음 해당 개체를 Get-Member cmdlet에 전달하는 것입니다.
Get-Item c:\scripts\test.txt | Get-Member
그림 1에서는 이 명령의 결과를 보여 줍니다. 이 결과를 보면 .NET 개체라는 것을 확실히 알 수 있습니다(Scripting Guy가 무엇인가 잘못한 것처럼!).
Figure 1 Get-Item이 반환하는 개체의 구성원 (Close Figure 1)

TypeName: System.IO.FileInfo

Name                      MemberType     Definition
----                      ----------     ----------
AppendText                Method         System.IO.StreamWriter AppendText()
CopyTo                    Method         System.IO.FileInfo CopyTo(String destFileName),
                                         System.IO.FileInfo CopyTo(S...
Create                    Method         System.IO.FileStream Create()
CreateObjRef              Method         System.Runtime.Remoting.ObjRef CreateObjRef(
                                         Type requestedType)
CreateText                Method         System.IO.StreamWriter CreateText()
우연히도 이 간단한 명령은 Windows PowerShell의 기능 중 파이프라인과 메타 정보라는 두 가지 흥미롭고 유용한 기능을 보여 줍니다. 오늘은 기술적인 내용을 자세하게 다루지는 않겠지만 파이프라인의 기본 개념은 cmdlet을 사용하여 개체를 가져와서 다른 cmdlet에 전달할 수 있다는 것입니다. 이 명령에서는 Get-Item cmdlet을 사용해서 C:\Scripts\Test.txt 파일을 나타내는 개체를 가져온 다음 해당 개체를 파이프라인을 통해 개체로 Get-Member cmdlet에 전달합니다. | 기호는 Windows PowerShell 명령에서 파이프라인을 나타냅니다.
그런 다음 Get-Member는 검색된 개체의 속성과 메서드를 검색하는 작업을 수행합니다. 이 기능은 Windows PowerShell의 여러 유용한 기능 중 하나입니다. 이 기능을 이용하면 정보에 대한 정보인 메타 정보에 쉽게 액세스할 수 있습니다. WMI 스크립트를 작성하여 사용 가능한 WMI 클래스, 속성 및 메서드에 대한 정보를 검색할 때와 마찬가지 방법으로 Get-Member 및 Get-Command와 같은 cmdlet을 사용하여 Windows PowerShell의 정보를 검색할 수 있습니다.
Get-Member는 WMI로 수행할 수 있는 작업보다 한 단계 발전된 기능을 제공합니다. WMI를 사용하여 WMI 개체 정보를 가져올 수 있지만 WMI로 다른 COM 개체(예: FileSystemObject)에 대한 정보를 가져올 수는 없습니다. 그러나 Windows PowerShell에서는 다릅니다. Get-Member는 사용자가 바인딩하거나 만들 수 있는 모든 개체에 대해 작동합니다. FileSystemObject를 사용할 때 사용할 수 있는 메서드가 기억나지 않나요? 그렇다면 다음 명령을 실행하십시오.
New-Object -comobject "Scripting.     FileSystemObject" | Get-Member
이 기능은 그리 많이 이용되지는 않지만 대단히 유용한 기능입니다.
훌륭하지 않습니까? C:\Scripts\Test.txt 파일에 대한 작업을 수행할 때 사용할 수 있는 속성 및 메서드 목록을 스크롤하면 다음 줄을 보게 될 것입니다.
LastWriteTime             Property       System.DateTime LastWriteTime {get;set;}
흥미로우시지요? 분명 LastWriteTime은 get(읽기)과 set(쓰기)을 모두 지원하는 속성입니다. 그렇다고 해서 Windows PowerShell을 이용해서 파일에 마지막으로 쓴 시간의 값을 변경할 수 있는 것일까요? 글쎄요.
Windows PowerShell 용어
별칭 기존 cmdlet을 나타내는 사용자 지정 가능한 이름입니다. Windows PowerShell에는 일반적인 셸 명령을 해당 cmdlet에 매핑하는 기본 별칭이 많이 있습니다.
Cmdlet Windows PowerShell의 최소 기능 단위이며, 다른 셸의 기본 제공 명령과 비슷합니다.
명령 Windows PowerShell의 실행 단위입니다. 명령에는 파이프로 연결된 여러 작업이 포함될 수 있으며 ; 문자를 사용하여 여러 줄로 분리할 수 있습니다.
프라푸치노 스타벅스에서 판매하는 아이스 커피입니다.
Monad/MSH/Microsoft Command Shell Windows PowerShell의 이전 코드명입니다.
개체 시스템이나 명령에서 검색되는 구조화된 데이터입니다. Windows PowerShell은 데이터를 .NET 개체로 조작하므로 텍스트 기반 명령 출력을 구문 분석할 필요가 없으며 이름을 사용하여 개체 속성을 조작할 수 있습니다.
매개 변수 명령줄에 사용되는 cmdlet의 옵션 집합입니다. Windows PowerShell에서는 처음에 하이픈(-) 문자를 사용하여 매개 변수를 지정합니다.
파이프라인 한 명령의 출력을 다른 명령의 입력으로 보내는 데 사용됩니다. 파이프라고도 하며 명령에서 | 문자로 표시됩니다.
프로필 Windows PowerShell이 시작될 때 로드되는 설정으로 셸의 작동 방법을 구성하는 데 사용됩니다.
스크립트 파일로 저장되어 실행되는 하나 이상의 명령입니다. Windows PowerShell에서는 .ps1 확장명을 스크립트 파일에 사용합니다.
셸 명령과 cmdlet을 모두 실행할 수 있는 명령줄 환경입니다.
변수 명령 실행 중에 값을 설정, 변경 또는 검색할 수 있는 개체 또는 매개 변수입니다.

이제 다시 Test.txt 파일에 마지막으로 쓴 시간을 현재 날짜 및 시간으로 설정하는 명령에 대한 이야기로 돌아가겠습니다. 예를 들면 다음과 같습니다.
$a = Get-Item c:\scripts\test.txt; $a.LastWriteTime = Date
실제로 이 명령은 매우 간단합니다. 먼저 $a라는 변수를 선언합니다. 그런 다음 Get-Item cmdlet을 사용하여 C:\Scripts\Test.txt 파일에 연결하고 해당 개체를 변수 $a에 저장합니다. 한 줄에서 여러 명령을 실행할 때 사용하는 세미콜론을 입력한 후 LastWriteTime 속성의 값을 현재 날짜 및 시간으로 설정합니다. 컵 홀더가 없는 아쉬움을 충분히 메워 주는 좋은 기능이지 않습니까?

응용하기
물론 마지막으로 쓴 시간을 현재 날짜 및 시간으로 설정하는 것 외에도 여러 작업을 수행할 수 있습니다. 다음 명령을 살펴보십시오.
$b = Get-Date "5/22/2006 8:15 PM";
$a = Get-Item c:\scripts\test.txt; $a.LastWriteTime = $b
이번에는 세 개의 명령을 연결했습니다. 먼저 Get-Date cmdlet을 사용하여 5/22/2006, 8:15 PM이라는 값을 가진 날짜 시간 개체를 만듭니다. 마지막으로 쓴 시간을 현재 날짜 및 시간으로 설정하는 첫 번째 스크립트에서 날짜 시간 개체를 만들 때 왜 Get-Date를 사용하지 않았을까요? 이유는 간단합니다. Date 명령은 자동으로 날짜 시간 개체를 반환하기 때문입니다. 직접 확인해 보려면 Windows PowerShell 콘솔에 Date | Get-Member 명령을 입력해 보십시오.
원하는 날짜 및 시간으로 설정된 날짜 시간 개체를 만든 다음에는 익숙한 Get-Item 명령을 사용하여 Test.txt 파일을 나타내는 개체(변수 $a에 저장한 개체)를 가져옵니다. 마지막으로 LastWriteTime 속성을 변수 $b가 나타내는 값으로 설정합니다.
$a.LastWriteTime = $b
믿어지지 않을 수도 있겠지만 지금까지 살펴본 기능은 일부에 불과합니다. 평범해 보이는 명령을 하나 살펴보겠습니다.
$b = Get-Date "5/22/2006 8:15 PM";
Get-ChildItem c:\scripts | ForEach-Object {$_.LastWriteTime = $b}
이 명령에 흥미로운 점이 있습니까? 이 명령이 어떤 기능을 수행하는지 살펴보시죠. 첫 번째 부분은 쉽습니다. 첫 번째 부분에서는 다시 한번 5/22/2006 8:15 PM이라는 값을 가진 날짜 시간 개체를 만듭니다. 그러나 두 번째 부분에서는 Get-Item cmdlet을 사용하지 않고 다음 명령을 사용합니다.
Get-ChildItem c:\scripts
이 명령의 핵심은 무엇일까요? Get-ChildItem cmdlet을 폴더에 적용하면 해당 폴더에 있는 모든 파일의 컬렉션이 반환됩니다. 컬렉션을 받아서 컬렉션의 모든 항목을 파이프라인(| 기호)을 통해 ForEach-Object cmdlet에 전달합니다.
이제 ForEach-Object는 이 모든 파일을 가지고 어떤 작업을 수행할까요? 그렇습니다. 다음과 같이 각 파일 및 모든 파일의 LastWriteTime 속성 값을 변경할 것입니다.
ForEach-Object {$_.LastWriteTime = $b}
참고 이 달의 칼럼은 Windows PowerShell 초보자를 위한 것이 아니기는 하지만 초보자를 위해 간단하게 설명하자면 $_는 For Each 루프의 현재 항목을 나타내는 특수한 변수로서 다음 VBScript 루프에 사용되는 objItem과 같습니다.
For Each objItem in colItems
    Wscript.Echo objItem.Name
Next
이 Windows PowerShell 명령의 실행이 종료되면 C:\Scripts 폴더에 있는 모든 파일의 마지막 쓴 시간이 동일한 시간으로 설정됩니다. 우리는 이 새로운 말 없는 마차가 움직이는 모습을 보고 싶습니다.
밤새도록 이 명령을 변형하여 실행할 수 있습니다. 예를 들어 C:\Scripts 폴더에서 .txt 파일의 마지막 쓴 시간만 바꾸고 싶으신가요? 물론 가능합니다. 말씀만 하십시오.
$b = Get-Date "5/22/2006 8:15 PM"; Get-ChildItem c:\scripts\*.txt | ForEach-Object {$_.LastWriteTime = $b}

올바른 선택
정말 멋지지 않습니까? 그러나 이 칼럼의 목적은 Windows PowerShell의 "판매를 권유"하거나 VBScript 스크립트를 던져 버리고 Windows PowerShell로 바꾸라고 권하는 것이 아닙니다. VBScript 스크립트를 계속 사용하고 싶고 필요하다면 그대로 사용하면 됩니다. 컴퓨터 관리에 사용되는 배치 파일, 명령줄 도구, 마법의 주문 및 다른 도구의 경우에도 마찬가지입니다. "고장나지 않은 것은 고치려고 하지 말라."는 말을 기억하십시오.
중요한 것은 기존에 이미 할 수 있는 작업을 Windows PowerShell이 할 수 있다는 것이 아닙니다. .NET Framework에 액세스할 수 있기 때문에 Windows PowerShell은 기존에 할 수 없었던 작업을 할 수 있다는 것이 중요한 것입니다. 파일에 마지막으로 액세스한 시간을 수정하는 것은 이러한 특징을 보여 주는 한 가지 예입니다. 필요한 작업이 무엇인가에 따라 다른 예제들도 얼마든지 만들 수 있습니다. 바로 이런 장점 때문에 Windows PowerShell을 살펴볼 가치가 있는 것입니다.
아마도 저희가 Windows PowerShell을 소개하는 방식이 낯설게 느껴지셨을 것입니다. 간단한 "Hello, world"와 같은 예제부터 시작하지 않고 여러 부분으로 구성된 Windows PowerShell 명령으로 바로 들어가 파이프라인이나 cmdlet과 같은 용어를 모두 알고 있는 것으로 간주하고 설명을 생략하다 보니 익숙하지 않게 느껴지는 분들이 많았을 것입니다. 이 같은 방식은 모두 의도적인 것이었습니다. 물론 Windows PowerShell을 사용해 보지 않은 사람이 많다는 것을 알고 있었지만 또 다시 컴퓨터에서 서비스 목록을 검색하는 방법을 보여 주게 되면 여러분이 새롭다는 느낌을 받지 못하고 저희의 설명을 귀담아듣지 않게 될 것이라고 생각했기 때문입니다.
여러분이 부디 운전하지 않고 있었기를 바랍니다. 대부분의 사람들에게는, "TechNet Magazine을 읽지" 않더라도 운전하면서 세 가지 음료수를 마시고, DVD를 보고, 휴대 전화를 받는 것 자체로 굉장히 어려운 일이지요.
모두가 그렇다는 것은 아니고 대부분이 그렇다는 것이지요.

Microsoft Scripting Guys는 Microsoft에서 근무하는 직원들입니다. 이들은 야구 경기를 하거나, 감독하거나, 관람하는 등의 일상적인 다른 활동을 하지 않을 때 TechNet 스크립트 센터를 운영합니다. 자세한 내용은 http://www.microsoft.com/korea/technet/scriptcenter/default.mspx에서 확인하십시오.


 Security Watch: 전역 트러스트된 PKI 배포
Security Watch
전역 트러스트된 PKI 배포
John Morello
이 칼럼에는 시험판 정보가 포함되어 있으며 모든 정보는 변경될 수 있습니다.

PKI(공개 키 인프라)는 다양한 응용 프로그램, 운영 체제 및 ID로 구성된 영역에서 트러스트를 형성하는 데 기본이 되는 요소입니다. PKI는 최종 엔터티가 최상위 루트 수준의 공용 키를 트러스트하며 이에 따라 해당 루트에 의해 서명된 다른 모든 키도 암시적으로 트러스트하는 계층적 트러스트 모델을 기반으로 합니다.
PKI는 이와 같이 구성되어 있으므로 올바르게 설계된 PKI의 경우 최종 엔터티를 변경하지 않고 인증 기관(CA) 추가만으로 쉽게 확장할 수 있습니다.
PKI는 일반적으로 두 가지 방법 중 하나를 통해 구현됩니다. 가장 일반적인 방법은 Cybertrust나 VeriSign과 같이 암시적으로 트러스트된 전역 루트 공급자 중 하나로부터 필요에 따라 인증서를 구입하는 것입니다. 이러한 인증서는 대개 웹 사이트의 트래픽에 보안을 설정하는 데 사용하지만 가상 사설망(VPN)을 암호화하거나 전자 메일에 서명하는 등의 작업에도 사용할 수 있습니다. 이러한 전역 루트는 현재 사용되는 모든 웹 브라우저와 운영 체제에서 기본적으로 제공하므로 조직의 경계를 넘어 트러스트 관계를 쉽게 확장할 수 있습니다. 그러나 이러한 인증서는 필요할 때마다 구입해야 하므로 대규모 조직에서 조직 전체에 배포할 경우 비용이 많이 드는 단점이 있습니다.
최근에는 내부 PKI 모델이 보다 널리 사용되고 있습니다. 이름에서도 알 수 있듯이 내부 PKI 모델은 조직 자체의 네트워크 내에서만 트러스트됩니다. 이 모델을 이용할 경우 조직은 보다 경제적으로 자체 네트워크의 모든 사용자와 컴퓨팅 장치에서 인증서를 사용하도록 할 수 있습니다. 이 방법은 대개 스마트 카드 로그온, EFS(파일 시스템 암호화) 및 보안 무선 네트워킹과 같은 기술을 활용하는 데 사용됩니다. 하지만 이러한 인증서는 전역에서 트러스트되지 않으므로 외부와 접한 응용 프로그램에는 적합하지 않다는 단점이 있습니다. 따라서 내부 PKI를 배포한 대부분의 조직에서는 일반적으로 전역 트러스트된 루트 중 하나로부터 인증서를 구입하여 공용 응용 프로그램에 사용하는 방법도 함께 채택하고 있습니다.
하지만 두 방법의 장점만 취할 수도 있습니다. 조직의 로컬 시스템을 통해 자체 PKI를 운영하여 내부 인증서를 발급함으로써 비용을 절감하는 동시에 공개 트러스트된 인증서도 제공할 수 있습니다. 이러한 솔루션을 사용하면 Active Directory® 통합, 자동 등록, 지역화된 IT 지원 등 내부 PKI가 지닌 이점과 더불어 전역 트러스트된 루트가 제공하는 주요 이점을 모두 누릴 수 있을 것입니다. LSU(루이지애나 주립 대학교)는 바로 이러한 시스템을 갖추고 있습니다. 이번 Security Watch 칼럼에서는 이 솔루션의 기술적 디자인에 대해 설명하고 이와 유사한 시스템을 배포할 때 사용할 수 있는 유용한 방법을 강조하면서 LSU에서 구현한 솔루션을 좀 더 면밀하게 검토해 보겠습니다. 이 솔루션은 LSU 고유의 환경, 리소스 및 비즈니스 요구 사항을 고려하여 특정한 필요성에 맞게 구현된 것이라는 점을 염두에 두어야 합니다. 따라서 사용자 조직에 적합한 솔루션을 결정하려면 먼저 해당 조직의 환경이나 요구 사항 등과 같은 측면을 모두 평가해야 합니다.

LSU의 PKI 운용 방식
LSU는 40,000명 이상의 학생, 교수 및 교직원이 있는, 규모가 큰 연구 중심 대학입니다. 이 대학에는 외부에 공개되는 많은 웹 사이트가 있으며 이러한 웹 사이트 대부분에는 SSL(Secure Sockets Layer) 인증서, 즉 전송 계층 보안이 필요합니다. LSU는 전역 트러스트된 루트 공급자로부터 인증서를 구입하는 데 연간 수천 달러를 지출하고 있었습니다.
한편 LSU는 올바르게 설계된 내부 PKI의 장점을 활용할 수 있는 다른 IT 보안 목표도 갖고 있었습니다. LSU의 목표와 요구 사항을 고려할 때 혼합 모델을 선택했을 것이라고 예상하기 쉽습니다. 그러나 LSU는 혼합 모델 대신 보다 혁신적인 방법을 선택했습니다.
먼저 전역 트러스트된 루트 중 하나인 Cybertrust와의 협력을 통해 Cybertrust 루트 CA에 종속된 하위 CA 하나를 LSU 교내에 배포했습니다(그림 1 참조). Cybertrust는 자체 OmniRoot 프로그램을 통해 이 서비스를 제공합니다. 이 시나리오에서는 LSU가 LSU 소유의 장치에서 로컬로 실행되는 CA를 만들어 운용합니다. 그러나 앞에서 설명한 내부 모델과는 달리 LSU의 CA는 자체 서명된 것이 아니므로 이 CA의 키 및 이 키로 서명된 모든 인증서가 현재 사용되는 거의 모든 운영 체제와 브라우저에서 암시적으로 트러스트됩니다. 기술적인 측면에서 이러한 설계는 x.509 표준의 개방성을 논리적으로 확장한 것입니다. PKI는 이러한 표준에 기반을 두고 있으므로 다양한 공급업체에서 만든 시스템을 동일한 계층 구조 전체로 연결하는 것이 가능합니다. OmniRoot 솔루션의 흥미로운 점은 이 서비스의 사용 약관입니다.
그림 1 Cybertrust 전역 루트 인증서
그림 1 Cybertrust 전역 루트 인증서 (더 작게 보려면 이미지를 클릭하십시오.)
그림 1 Cybertrust 전역 루트 인증서
그림 1 Cybertrust 전역 루트 인증서 (더 크게 보려면 이미지를 클릭하십시오.)
OmniRoot 서비스는 LSU에서 구현한 PKI 배포 유형에 맞게 설계된 것입니다. OmniRoot 프로그램을 이용하는 조직은 프로그램 참여에 대해 정해진 연간 비용을 Cybertrust에 지불하고, 인증서 단위 비용은 공용 인증서에 대해서만 지불합니다. 다시 말해 LSU는 내부용 인증서가 필요할 때마다 비용이 추가되는 것을 염려하지 않고도 얼마든지 인증서를 발급할 수 있습니다. 또한 필요할 때마다 구입하는 공용 인증서의 가격도 이전보다 훨씬 저렴해졌습니다.
기술적인 측면에서 내부 인증서와 공용 인증서는 동일합니다. 두 인증서 모두 동일한 CA 체인에서 발급되고 암호화 수준이 동일하며 동일한 등록 기관 시스템을 통해 제공됩니다. 두 인증서의 유일한 차이점은 사용 약관입니다.
LSU는 이러한 혼합 방법을 채택함으로써 IT 보안 플랫폼을 보다 저렴한 비용으로 확장하고 개선할 수 있었습니다. 이와 같은 성과를 통해 LSU의 PKI 솔루션은 이와 비슷한 유형의 환경에 적합한 훌륭한 비즈니스 사례가 되었습니다. 이제 이 PKI 배포의 기술적 측면을 좀 더 자세히 살펴보겠습니다.

PKI 계층 구조
LSU의 PKI 계층 구조는 Cybertrust에서 관리하는 루트 계층과 LSU에서 실행되는 온라인 발급 CA로 구성된 2계층 디자인을 기반으로 합니다(그림 2 참조). 루트 계층은 계층 구조에서 트러스트의 기준 위치가 됩니다. 다시 말해 계층 구조의 CA가 발급한 모든 인증서의 트러스트 관계는 루트 CA 아래에 놓입니다(그림 3 참조). 따라서 루트 CA가 계층 구조의 모든 CA, 인증서 및 최종 엔터티 간에 공통된 연관 관계를 형성하게 됩니다. Cybertrust 전역 루트는 Windows®와 현재 사용되는 거의 모든 컴퓨팅 시스템에서 기본으로 제공하므로 이와 같은 공통된 연결 관계는 LSU의 네트워크를 넘어 자동으로 확장됩니다.
Figure 2 2계층 PKI 계층 구조 (Close Figure 2)

루트 계층(Cybertrust) | 발급 계층(LSU)
Cybertrust에서 관리 | LSU에서 관리
Cybertrust의 안전한 데이터 센터에 위치 | LSU의 배턴루지 캠퍼스에 위치
오늘날 거의 모든 컴퓨팅 시스템의 기본 루트 인증서에 포함됨 | LSU 시스템 조직 내의 최종 엔터티에 인증서 발급
 | LSU에서 발급한 인증서는 Cybertrust 루트 아래에 놓이며 전역에서 트러스트됨
그림 3 LSU의 발급 CA에서 발급한 인증서
그림 3 LSU의 발급 CA에서 발급한 인증서 (더 작게 보려면 이미지를 클릭하십시오.)
그림 3 LSU의 발급 CA에서 발급한 인증서
그림 3 LSU의 발급 CA에서 발급한 인증서 (더 크게 보려면 이미지를 클릭하십시오.)
Cybertrust는 자체 보안 호스팅 시설 중 하나에서 루트 CA를 관리합니다. 이 호스팅 시설에서는 침입 감지 장치, 생체 인식 잠금 장치, 구리로 도금한 저장소를 비롯하여 강력한 물리적 보안 장치를 사용합니다. Cybertrust는 자사의 보안 및 인증서 정책을 준수할 것을 약속한 조직의 발급 CA에만 인증서를 발급합니다.
LSU의 발급 CA는 LSU의 사용자와 시스템에 인증서를 제공하는 역할을 담당하는 최종 엔터티 지향 시스템입니다. 여기에서 발급하는 인증서는 계층 구조에서 바로 위에 있는 Cybertrust CA에 의해 서명되고 발급 CA를 거쳐 Cybertrust 루트 CA로 연결됩니다(그림 3 참조).

발급 OS 및 하드웨어
LSU는 발급 CA로 Windows Server® 2003 Enterprise Edition 서비스 팩 1을 사용합니다. Windows Server 2003 인증 기관 서비스는 키 저장, 델타 CLR(인증서 해지 목록) 및 "버전 2" 템플릿을 비롯하여 다양한 새로운 기능을 제공합니다. 발급 CA로 사용되는 Windows 인스턴스는 표준 LSU Windows Server 빌드 정책에 따라 구축되었습니다. 이 Windows 인스턴스는 관련 보안 업데이트가 나올 때마다 업데이트되고 표준 LSU 변경 관리 방법, 소프트웨어 인벤토리 및 업데이트 도구를 통해 관리됩니다. 간단히 말해, 기본 서버 하드웨어와 운영 체제를 사용하면 CA 서비스 자체를 관리하는 데 있어 몇 가지 고유한 측면이 있지만 조직의 기존 IT 운용 환경에 쉽게 통합할 수 있는 장점도 있습니다.
다음에 나오는 LSU의 서버 설치를 위한 일반적인 최선의 방법 외에도 LSU는 Windows Server 2003 서비스 팩 1에서 사용할 수 있는 보안 구성 마법사(SCW)를 활용했습니다. SCW는 Windows Server에서 실행될 수 있는 다양한 작업의 종속성 매트릭스와 이러한 작업에 필요한 보안 설정이 있는 데이터베이스를 사용합니다. 이 데이터베이스에는 CA가 제공하는 두 가지 주요 역할인 CA 서비스 자체 및 IIS(PKI 셀프 서비스 웹 사이트 제공)가 있습니다.
SCW를 사용함으로써 이러한 작업을 실행하는 데 필요한 것 이외의 모든 서비스를 비활성화하는 보안 템플릿을 쉽게 만들 수 있었고 서버의 네트워크 스택도 강화할 수 있었습니다. 그런 다음 이 보안 템플릿을 조직 구성 단위 수준에서 서버에 적용할 수 있도록 scwcmd.exe를 사용하여 그룹 정책 개체(GPO)로 변환했습니다. 이러한 방법을 통해 LSU CA의 역할 기반 보안 구성이 이제 Active Directory 내에 저장되어 모든 시스템에서 동일해졌고 이에 따라 확장 및 장애 복구 작업이 간편해졌습니다.
LSU의 발급 CA는 듀얼 3.2GHz Intel Xeon 프로세서, 4GB의 RAM 및 5개의 146GB SCSI 하드 디스크가 장착된 IBM xSeries 346 서버에 구축되었습니다. CA 서비스의 성능 요구 사항과 LSU가 하드웨어 보안 모듈을 이용한다는 사실을 감안할 때 이 플랫폼은 긴 수명과 확장성을 제공해야 했습니다.
따라서 두 개의 RAID 1 배열을 만들어 데이터베이스와 로그 파일을 별도의 물리적 하드 디스크에 분리하는 일반적인 최선의 방법을 따랐습니다. 다섯 번째 하드 디스크는 핫 스페어(Hot Spare)로 지정하여 두 배열 중 하나에서 사용할 수 있게 만들었습니다. 첫 번째 배열을 시스템 볼륨으로 탑재하여 CA 데이터베이스를 저장했고 두 번째 배열은 로그 파일과 CRL 등의 기타 다양한 데이터 파일을 저장하는 데 사용했습니다. CA 데이터베이스는 Active Directory 등 Windows의 다른 부분에 사용된 것과 동일한 Jet 기술을 기반으로 하므로 다른 Jet 기반 저장소 솔루션에 사용되는 것과 동일한 유지 관리 및 디스크 구성 방법이 적용됩니다.
HSM(하드웨어 보안 모듈)은 운영 체제와는 별도로 관리되는 전용 하드웨어 장치입니다. 일반적으로 HSM은 PCI 어댑터로 제공되지만 네트워크 기반 장치로도 사용할 수 있습니다. 하드웨어 보안 모듈은 CA 키를 저장할 수 있는 안전한 하드웨어 저장소와 더불어 서명 및 암호화 작업의 속도를 높이는 전용 암호화 프로세서를 제공합니다. Windows에서는 CryptoAPI 인터페이스를 통해 HSM을 사용하며 HSM은 CSP(암호화 서비스 공급자) 장치로 표시됩니다. OmniRoot 프로그램을 통해 키를 생성하고 저장하려면 각 CA가 최소한 FIPS 140-2 수준 3(수준 4 장치는 거의 사용되지 않음) 인증 HSM을 사용해야 합니다. 독창적이고 매우 안전한 장치인 HSM을 사용하려면 많은 비용을 투자해야 하는데, PCI 기반 HSM의 일반 소매 가격은 10,000달러에서 15,000달러 안팎입니다.
LSU 디자인에는 직접 연결 HSM으로 nCipher nShield 500TPS(초당 500개의 트랜잭션 모델)가 사용되었습니다. 여기서 "직접 연결"이란 여러 호스트가 공유할 수 있는 네트워크 기반 HSM과는 달리 HSM이 서버 내부에 설치되어 해당 서버에서만 사용할 수 있음을 의미합니다. HSM은 FIPS 140-2 수준 3 장치이며 키 관련 자료를 K of N 방식으로 보호합니다. HSM은 개인 키가 손상되지 않도록 철저하게 보호합니다. 공격자가 키에 액세스하려면 HSM 저장소를 비롯하여 정의된 개수의 액세스 토큰과 해당 PIN을 모두 가지고 있어야 합니다.
HSM은 해당 콘텐츠를 악의적 의도를 지닌 제3자가 손상시키지 못하게 보호하도록 설계되었습니다. 따라서 HSM은 실패한 연속 로그온 시도 횟수에 대한 제한을 엄격하게 적용합니다. LSU 디자인에서는 연속적으로 10번 로그온에 실패하면 저장소가 영구히 삭제됩니다.
이 솔루션에서는 CA를 하나만 구현했으므로 네트워크 기반 HSM에 투자한 비용만큼 그 혜택을 모두 거둬들일 수는 없었습니다. 그러나 CA를 두 개 이상 구현하려는 조직에서는 네트워크 기반 HSM을 하나만 구입하여 여러 CA에서 공유할 수 있으므로 훨씬 저렴한 비용으로 HSM을 이용할 수 있습니다. 또한 동일한 토큰 집합으로 모든 키 저장소를 보호할 수 있으므로 토큰 관리도 편리해집니다.

Active Directory 및 등록
Windows 기반 PKI 솔루션이 제공하는 주요 장점 중 하나는 PKI에 참가하는 엔터티에 추가 소프트웨어를 설치하지 않고도 인증서 제공이 이루어진다는 점입니다. 더 정확하게 말하자면 자동 등록과 그룹 정책을 함께 사용함으로써 대부분의 인증서 제공을 최종 사용자에게는 보이지 않게 자율적으로 관리할 수 있다는 점입니다. LSU는 이 기술을 사용하여 컴퓨터 인증서를 해당 Active Directory의 구성원인 컴퓨터에 자동으로 배포합니다. 그리고 Windows가 아닌 호스트에는 사용자 지정 웹 사이트를 통해 셀프 서비스 인증서 요청 기능을 제공하고 있습니다.
앞에서도 설명했듯이 OmniRoot 프로그램은 공용 인증서와 내부용 인증서를 구분합니다. LSU 조직에 포함되지 않은 시스템이나 사용자가 사용하는 인증서는 공용으로 간주됩니다. 예를 들어 수험생이 SSL 보안 웹 사이트를 통해 입학 지원서를 전송할 때 사용하는 인증서는 공용 인증서입니다. LSU 조직 내에서 사용되는 인증서는 내부용으로 간주됩니다. 예를 들어 LSU 서버의 데이터를 암호화하는 데 사용되는 인증서는 내부용 인증서입니다.
OmniRoot 프로그램을 이용하는 비용은 공용 인증서의 개수에 따라 달라지므로 얼마나 많은 공용 인증서가 어떤 사용자에게 발급되었는지를 추적할 수 있어야 했습니다. 따라서 용도가 공용인 모든 인증서는 템플릿 이름이 "PublicCertificate"로 시작하고 표시 이름이 "Public Certificate"로 시작하도록 지정하여 구분했습니다. 예를 들어 공용 LSU TLS 인증서 템플릿은 기본 Windows 웹 서버 템플릿을 기반으로 하며 공용 인증서 LSU 웹 서버라고 합니다. 내부용으로 사용되는 웹 서버에는 내부 인증서 LSU 웹 서버라는 두 번째 템플릿을 사용합니다. 기술적인 측면에서는 두 템플릿이 동일하며 어떤 템플릿이 공용이고 어떤 템플릿이 내부용인지를 구별하기 쉽도록 이름을 다르게 지정하는 것일 뿐입니다.
대량 등록이 필요한 경우, 예를 들어 학부 전체를 등록해야 할 경우에는 IPSec과 함께 인증서를 사용해야 하므로 이때는 자동 등록에 의존합니다. 자동 등록은 Windows에서 기본으로 제공하는 단순하면서 매우 효율적인 도구입니다. PKI 관리자는 인증서가 필요한 사용자 또는 컴퓨터 그룹에 자동 등록 권한을 부여함으로써 템플릿에 대한 액세스 제어 목록을 변경하기만 하면 됩니다. 그런 다음에는 이러한 엔터티가 자동으로 Active Directory를 확인하여 자동 등록 권한을 가진 템플릿을 열거하고 해당 템플릿을 소유한 CA를 찾은 다음 자동으로 인증서에 등록합니다. 또한 자동 등록 기능은 템플릿이 대체된 경우 인증서를 대체함으로써 인증서가 만료되기 전에 자동으로 갱신합니다.
LSU에서는 웹 서버에 인증서를 제공하는 것과 같이 인증서를 대량으로 사용하는 경우가 아니면 사용자가 웹 브라우저를 통해 인증서를 요청할 수 있는 셀프 서비스 웹 사이트를 이용하고 있습니다. 이 셀프 서비스 웹 사이트는 Windows Server 2003(/certsrv 가상 디렉터리)에 제공되는 웹 등록 페이지를 필요에 맞게 바꾼 것으로, LSU에 구현된 사이트에는 LSU의 표준 웹 브랜딩이 포함되어 있고 요청 페이지에는 올바른 기본 항목이 미리 채워져 있습니다. 또한 이 사이트를 통해 전송되는 요청에 승인이 필요한 경우에는 PKI 관리 팀에 자동으로 전자 메일을 보내도록 Windows CA 서비스의 기본 끝내기 모듈을 사용했습니다.

해지 디자인
각 인증서에는 유효 기간이 있습니다. 간혹 인증서 유효 기간이 끝나기 전에 인증서를 무효로 만들어야 할 경우가 있습니다. 예를 들어 2007년 5월에 유효 기간이 만료되는 인증서를 직원에게 부여했는데 해당 직원이 2007년 1월에 LSU를 퇴사하는 경우가 있습니다. 이러한 유형의 해지는 CA에서 서명한 인증서 일련 번호 목록이 포함된 파일인 CRL을 통해 수행됩니다. CRL에 들어 있는 일련 번호는 유효 기간이 만료되지 않았지만 LSU에서 더 이상 신뢰할 수 없는 것으로 간주하는 인증서를 나타냅니다. 클라이언트는 이 CRL을 다운로드하여 대조해 봄으로써 인증서가 유효한지를 확인할 수 있습니다.
루트 CA 인증서 자체를 제외한 모든 x.509 v3 인증서에는 올바른 CRL에 대한 포인터가 있어야 합니다. 이 포인터를 CRL 배포 지점(CDP)이라고 합니다. CRL 배포 지점은 인증서 자체에 포함되며(그림 4 참조) 인증서가 발급된 후에는 수정할 수 없습니다. CRL은 CA에서 발급한 인증서가 유효한 인증서임을 보증하는 데 반드시 필요한 요소입니다. 따라서 LSU CRL은 물리적으로 중복되고 항상 사용할 수 있으며 외부 사용자의 액세스가 가능하도록 만들었습니다.
그림 4 LSU의 CRL 배포 지점
그림 4 LSU의 CRL 배포 지점 (더 작게 보려면 이미지를 클릭하십시오.)
그림 4 LSU의 CRL 배포 지점
그림 4 LSU의 CRL 배포 지점 (더 크게 보려면 이미지를 클릭하십시오.)
LSU의 경우처럼 Active Directory와 통합된 Windows Server 기반 CA는 자체 CRL을 자동으로 Active Directory에 게시하여 LDAP(Lightweight Directory Access Protocol)를 통해 액세스할 수 있게 만듭니다. 기본 게시 위치는 포리스트의 Public Key Services 컨테이너 내에 있는 CDP 컨테이너(그림 5 참조)입니다. 이 게시 위치는 자동 복제, 내결함성 및 CDP 조회 위치를 제공하는 매우 편리한 옵션입니다.
그림 5 CDP 컨테이너
그림 5 CDP 컨테이너 (더 작게 보려면 이미지를 클릭하십시오.)
그림 5 CDP 컨테이너
그림 5 CDP 컨테이너 (더 크게 보려면 이미지를 클릭하십시오.)
그러나 LSU의 디자인에는 PKI를 활용하지만 Windows와 Active Directory에 기반을 두지 않는 컴퓨터가 많이 있습니다. 또한 LSU가 대규모 조직인 반면 대부분의 사용자가 10Gbps의 백본을 갖춘 동일한 캠퍼스 네트워크에 있어서 Active Directory 기반 CDP 게시를 이용함으로써 얻을 수 있는 장점도 많지 않았습니다.
따라서 CRL을 HTTP 경로에만 게시하여 중복 호스팅 플랫폼을 구축하기 쉽게 만들었습니다. LSU의 주요 웹 사이트는 이미 미러되어 있었습니다. 이를 통해 클라이언트 LDAP 조회를 사용함으로써 발생할 수 있는 잠재적 복잡성도 사라졌습니다. LSU에서는 CRL은 매일 게시하고 델타 CRL은 매시간 게시하고 있습니다.

향후 방향
LSU의 PKI가 대학 커뮤니티에 강력한 보안 솔루션을 제공하고 있지만 앞으로는 그 기능을 더욱 개선하려는 계획을 가지고 있습니다. Windows Vista™와 차세대 Windows Server(코드명 "Longhorn")는 우리가 검토하고 있는 수많은 새로운 키 관리 기능을 제공할 것입니다. 그 중에서도 특히 많은 관심을 가지고 있는 기능이 OCSP(온라인 인증서 상태 프로토콜) 클라이언트/응답자 기능, Elliptic Curve 암호화 및 SHA-256 알고리즘 지원, 대폭 개선된 자동 등록 인터페이스입니다. 뿐만 아니라 Windows XP 서비스 팩 3에는 로밍 프로필과 관련된 오버헤드를 발생시키지 않고 키 쌍을 안전하게 로밍할 수 있게 해 주는 자격 증명 로밍이라는 기능이 포함될 예정입니다. 마지막으로 보고 및 관리 기능을 개선하기 위해 현재 베타 버전으로 제공되는 Certificate Lifecycle Manager를 사용하는 것도 검토 중에 있습니다.
이 글의 내용을 요약하면 LSU의 PKI는 대부분의 중요한 IT 기능에 사용되는 기본적인 보안 서비스를 대학에 제공하고 있습니다. 우리는 Cybertrust의 OmniRoot 서비스를 사용함으로써 LSU의 다른 IT 시스템과 적절히 통합되면서 트러스트 범위가 전역으로 확장되는 PKI를 구현할 수 있었습니다. 또한 Windows CA 서비스를 기반으로 이 솔루션을 구축함으로써 효율적인 인증서 제공 및 관리 기능을 활용할 수 있었고 기존의 디렉터리 및 ID 관리 시스템과도 적절하게 통합할 수 있었습니다. 강력한 보안과 완벽한 트러스트라는 PKI의 비전이 LSU에서는 이미 현실로 나타나고 있습니다.

John Morello는 루이지애나 주립 대학교를 수석으로 졸업했으며 Microsoft Consulting Services에서 수석 컨설턴트로 6년간 근무했습니다. MCS에서 재직하는 동안 John Morello는 Deloitte, GE, 다양한 연방 정부 산하 기관 등의 전략적 클라이언트를 위해 PKI를 설계했습니다. John Morello는 현재 LSU의 부 CISO(최고 정보 보호 책임자)입니다.


 The Desktop Files: Windows 이미징 형식 내부
The Desktop Files
Windows 이미징 형식 내부
Wes Miller
이 칼럼은 Windows 배포 도구의 시험판 버전을 기준으로 작성되었습니다. 이 문서에 수록된 모든 정보는 변경될 수 있습니다.

Windows Vista가 출시되면 Windows의 설치 및 배포 방법이 크게 변경될 것입니다. Windows Vista 및 차세대 Windows Server 버전(코드명 "Longhorn")의 설치 엔진과 전체 배포 도구 집합이 새로 작성되었습니다. 저는 최근 TechNet Magazine 기사에서
Windows® 배포 팀이 이러한 변경을 위해 수행한 작업을 설명한 적이 있습니다. 그러나 이 주제에 관하여 설명할 것들이 많으므로 본 정기 칼럼에서는 Windows PE, Windows 설치와 배포, Windows와 관련된 기타 관리 및 보안 문제를 다룰 것입니다.
첫 번째인 이번 칼럼에서는 새로운 WIM(Windows 이미징 형식)에 대해 살펴보겠습니다. 이미징에 대해 잘 모르는 경우에는 오른쪽 아래에 있는 "일반적인 이미징 프로세스"를 읽고 이미징의 개념을 알아두는 것이 좋습니다. 다음 칼럼에서는 ImageX(WIM 이미지 생성 및 조작에 사용되는 명령줄 도구)가 포함된 새로운 도구 집합인 Windows 자동 설치 키트와 RIS(원격 설치 서비스)를 대체하는 WDS(Windows 배포 서비스)를 통해 OS 배포가 얼마나 간편해지는지를 살펴볼 것입니다.

전환점
수년에 걸쳐 Windows 배포 팀은 OEM 및 기업 고객으로부터 매번 같은 의견을 받았습니다. OEM과 기업 고객은 이미징에 대한 지원이 개선되기를 바랐고 Microsoft가 통합된 이미징 도구를 제공하기를 원했습니다. 이들은 타사 공급업체를 선택하고 해당 공급업체의 제품 기능을 배워야 하는 것이 부담스러웠습니다. 더욱이 Windows를 배포하는 데 사용하는 이미징 도구를 비용을 지불하고 구입해야 하는 것에도 불만이 많았습니다. 고객은 Microsoft가 이러한 도구를 제공해 주기를 희망했습니다.
Windows Vista™ 개발 초기에 Windows 배포 팀은 매우 큰 모험을 감행했습니다. Windows 배포 팀은 전체 설치 엔진을 과감하게 폐기하기로 결정했는데, 이 엔진을 구성하는 대부분의 구성 요소는 거의 10년 동안 사용되던 것들이었습니다. 설치 프로그램은 늘 안정성이 부족했고 단계가 너무 많았습니다. 따라서 설치 프로세스의 속도를 높이고 불필요한 단계는 제거하여 Windows 설치 프로그램의 안정성을 전반적으로 개선하고 싶었습니다. 이를 위해 꽤 오랫동안 사용해 왔던 기존 엔진에서 탈피하여 완전한 이미지 기반 설치 프로세스로 전환하려고 했습니다.

새로운 이미징 형식 설계
설치 프로그램을 다시 설계하는 과정에서 초기에는 사용해야 할 이미지의 종류를 정의하는 일에 착수했습니다. 섹터와 파일 중 어느 것을 기본으로 할지에 대한 논쟁이 벌어졌습니다. 즉, 볼륨 복사본을 섹터 단위 복제본으로 저장하는 이미지 형식과 모든 단일 파일을 개별적으로 저장하는 이미지 형식 중 어떤 것을 사용할지를 결정해야 했습니다. 대부분의 사람들이 예상하는 이점은 섹터 기반 방법을 이용할 경우 얻게 되는 속도와 파일 기반 방법을 이용할 경우 얻게 되는 압축 성능입니다. 결국 두 방법의 이점을 고루 얻을 수 있는 형식을 사용하기로 결정했습니다. 이 형식은 뛰어난 성능과 함께 우수한 압축 기능도 제공합니다.
먼저 OEM과 기업 사용자의 요구 사항을 충족하는 이미징 형식을 만들기 위해 달성해야 할 몇 가지 주요 목표를 정의했습니다. 배포 팀이 정의한 목표들을 보면 파일 기반 아키텍처가 상당한 지지를 받고 있었습니다. 배포 팀 모두 이 방법의 장점을 알고 있었고 따라서 먼저 이 방향에서 작업을 시작했습니다. 그리고 얼마 지나지 않아 WIM 파일을 개발했습니다. 궁금해하실 것 같아 말씀드리지만 WIM에서 "M"은 아무 것도 의미하지 않습니다. 릴리스 기준 시점이 다가오면 늘 열리는 Windows 팀 회의에서 취합된 의견에 따라 WIM이라고 명명했습니다. *.WI라고만 하기에는 약간 이상해 보였기 때문이었습니다. 이제 새로운 이미지 형식을 만들기 위해 Windows 배포 팀이 설정한 목표를 살펴보도록 하겠습니다.
Windows 파일 시스템 형식에 중립적 Windows에서 지원하는 두 파일 시스템 아키텍처 모두에서 이미지 형식이 작동해야 합니다. 실행되는 대부분의 시스템에서 NTFS를 사용하기는 하지만 많은 OEM과 기업에서는 MS-DOS®를 이용한 Windows 배포가 가능하도록 FAT 파일 시스템을 임시 방법으로 사용하고 NTFS로의 변환은 나중에 수행합니다. 따라서 Windows Vista에서도 FAT 파일 시스템을 계속해서 지원해야 했습니다.
볼륨 구조에 중립적 대용량 볼륨을 캡처하여 보다 작은 볼륨에 적용해야 하는 기존의 문제를 극복해야 했습니다. 이미징 도구를 사용할 경우 파티션 조작과 같은 방법으로 이 문제를 극복할 수는 있지만 안정적이지 않았습니다. In a file-based architecture, the image only takes up as much space as the files that comprise it. 파일 시스템은 독립적으로 복원되므로 볼륨 크기에 의존할 필요가 없습니다.
일반적인 이미징 프로세스
OEM이 다수의 시스템을 복제하거나 대규모 조직에서 수많은 컴퓨터에 Windows를 배포해야 할 때 주로 이미징 기술을 이용합니다. 단, 이미징 기술을 이용하려면 호스트 시스템을 설정하고 원하는 대로 정확하게 구축한 다음 대상 시스템에 복제해야 합니다. 이미징 프로세스에 익숙하지 않은 경우 아래의 간단한 개요를 살펴보십시오.
  1. 관리자가 시스템에 Windows를 설치한 다음 원하는 대로 구성합니다. 이때 구성 요소를 추가하거나 제거하고 일반적으로 사용되는 응용 프로그램을 설치하고 UI와 기타 설정을 수정하는 작업이 수반됩니다. 이 시스템을 호스트 시스템이라고 합니다.
  2. 그런 다음 관리자가 Microsoft가 Windows 배포 도구로 제공하는 Sysprep을 실행합니다. Sysprep은 컴퓨터 이름, Windows SID(보안 식별자) 및 기타 시스템 전반에 걸친 고유 ID와 같이 Windows 설치를 고유하게 만드는 특성을 정리하는 복잡한 작업을 수행합니다. 이러한 특성은 Sysprep이 실행되는 후반에 다시 설정됩니다.
  3. 관리자가 컴퓨터를 종료하고 이미징 응용 프로그램을 실행할 수 있는 Windows PE, MS-DOS 또는 다른 OS로 다시 부팅합니다.
  4. 이제 관리자가 이미징 도구를 실행하여 참조 시스템의 이미지를 만듭니다. 이 이미지는 참조 디스크 또는 파티션의 정확한 복제본이 들어 있는 파일 또는 파일 모음입니다.
  5. 시스템이 종료되고 관리자가 이미지를 보관합니다. 필요한 경우 응용 프로그램, 핫픽스 및 서비스 팩을 추가하여 이미지를 업데이트할 수 있습니다.
  6. 하나 이상의 컴퓨터로 이미지가 복제되고 Sysprep은 간략화된 설치 프로그램(Sysprep을 실행하는 Windows 버전 및 Sysprep의 구성 방식에 따라 최소 설치 또는 Windows 시작이라고 함)을 실행하여 작업을 완료합니다. 이 단계는 setupcl.exe라는 작은 기본 모드 실행 파일을 통해 수행됩니다.

시스템 아키텍처에 중립적 Windows가 지원하는 모든 아키텍처에서 이미지 아키텍처가 작동해야 했습니다. 그 당시 이것은 매우 다른 성격을 띤 x86 및 IA64(Intel Itanium) 아키텍처를 지원하는 것을 의미했습니다. 현재는 지원해야 할 아키텍처에 x64(AMD64 및 EM64T) 아키텍처도 포함됩니다.
고속 이미지 캡처 및 적용 압축을 한다고 가정했을 때 이미지 캡처 속도가 빨라야 했습니다. 하지만 보다 중요한 것은 이미지를 적용할 때 그 속도가 매우 빨라야 한다는 것입니다.
기존 데이터를 보존하는 이미지 적용 지원 사용자 데이터나 응용 프로그램에 아무런 영향을 주지 않고 Windows를 대체하는 업그레이드 옵션과 시스템 복구에 사용할 수 있는 도구를 새로 모색하고 있었으므로 볼륨에 이미 존재하는 데이터는 손상시키지 않고 시스템에 대한 이미지를 만들려고 했습니다. 일반적으로 복원을 수행할 때는 볼륨 전체를 복원하거나 복원을 아예 수행하지 않으므로 섹터 기반 형식의 경우 상당량의 작업이 수반되지 않고서는 사용자가 이 작업을 수행할 수 없습니다.
향상된 압축 지원 Windows Vista 개발 작업을 처음 시작할 때만 해도 Windows를 CD로 제공하는 것에 중점을 두고 있었습니다. Windows XP 이미지의 크기가 1GB에 이른다는 점을 고려했을 때 이미지를 가능한 한 고밀도로 압축하는 것이 중요하다고 생각했습니다. 섹터 기반 이미지의 경우 몇 가지 방법을 통해 이러한 압축이 가능할 수도 있지만 이 경우 이동되는 부분이 염려스러웠습니다. 대부분의 섹터 기반 형식은 디스크의 공백을 생략하여 공간을 절약합니다. 0이 항상 0이라면 이미지에 0을 기록해야 할 필요가 없으니까요. 하지만 배포 팀에서는 파일 기반 방법을 통해 공백을 선택하지 않음으로써 이 문제를 처리했습니다.
파일의 단일 인스턴싱 지원 이 문제는 앞의 문제와 동일합니다. Windows에서는 동일한 파일의 여러 복사본을 몇몇 다른 위치에 저장합니다. 파일 기반 방법을 이용한다면 각 파일의 인스턴스를 하나만 저장하고 필요에 따라 파일을 사용하는 것이 쉽습니다.
미디어(디스크) 확장 지원 WIM의 초기 단계에 한 장의 CD에 맞게 이미지를 만들 수 있었을 때조차도 여러 개의 미디어를 지원해야 한다는 사실을 잘 알고 있었습니다. Windows를 CD 한 개로 제공하더라도 사용자가 응용 프로그램과 서비스 팩 등을 추가하면 CD나 DVD 한 개에 담기에는 이미지 크기가 점점 커질 것입니다. 따라서 Windows 설치와 복구를 위해 여러 개의 미디어에 이미지를 확장할 수 있도록 지원해야 했습니다.
하나의 파일 BLOB에서 여러 개의 볼륨 이미지 지원 하나의 이미지로 모든 것을 해결할 수 있는 경우는 거의 없습니다. "단일 인스턴싱"을 엔지니어링할 때 볼륨을 둘 이상 선택할 수 있는 기능 및 압축과 단일 인스턴싱이 상호 작용하도록 하는 기능도 포함했습니다. 따라서 Windows XP Professional 이미지를 선택한 다음 Windows XP Tablet PC Edition(Windows XP Professional의 상위 집합)에 대한 새 이미지를 추가하면 두 버전 간에 명시적으로 다른 부분에 해당하는 파일 수만큼만 이미지 크기가 늘어납니다.
그 결과 OEM이나 기업 사용자는 이미지 크기가 빠른 속도로 늘어나는 것을 염려하지 않고 각 버전에 많은 파생 이미지를 추가할 수 있습니다. 섹터 기반 형식에서는 이를 실현하기가 쉽지 않았을 것입니다.

WIM의 작동 방식
WIM 형식은 배포 팀이 설정한 주요 원칙을 충족하는 동시에 가능한 한 단순한 형태가 되도록 설계되었습니다. 파일 기반 방법을 이용했기 때문에 이와 같은 일이 가능했습니다. 이제 WIM이 정확하게 어떻게 작동하는지 살펴보겠습니다.
간단히 말해 WIM 파일은 CAB 파일이라고 생각할 수 있습니다. CAB 형식은 ZIP 형식과 비슷하지만 Microsoft에서 설계했고 Microsoft가 소유한 형식입니다. 실제로 WIM이 "CAB의 후예"로 불리는 것을 들은 적이 있습니다. WIM 파일과 CAB 파일의 가장 큰 차이점은 WIM 이미지의 경우 파일 자체를 캡처하고 압축할 뿐만 아니라 지정된 볼륨 이미지에 캡처된 볼륨을 구성하는 파일과 디렉터리에 적용되는 메타데이터 또한 저장한다는 것입니다. 따라서 WIM 파일은 이미지가 만들어진 시점의 볼륨 상태로 볼륨을 복원하는 데 필요한 ACL(액세스 제어 목록), 짧은 파일 이름/긴 파일 이름, 특성 등의 모든 메타 정보가 포함된 일종의 보관 파일이라고 할 수 있습니다.
하지만 캡처하는 동안에는 크기나 형식과 같은 파티션 정보가 수집되지 않으며 이미지를 적용하는 동안에는 시스템이 분할되지 않습니다. 대부분의 이미징 도구와는 달리 ImageX는 파티션에 중립적이므로 이미지를 적용하기 전에 파티션을 만들고 포맷해야 합니다. 이미지를 적용하기 전에 이 프로세스를 자동화하려면 diskpart 및 format 명령줄 도구를 사용해야 합니다.
볼륨 이미지에 저장할 수 있는 것에는 제한이 없습니다. 두 개의 볼륨, 화요일과 목요일에 캡처된 동일한 볼륨, 서비스 팩이 포함된 이미지와 포함되지 않은 이미지 등 필요한 모든 것을 이미지에 저장할 수 있습니다. 중요한 것은 동일한 파일은 한 번만 캡처된다는 점입니다. 즉, 두 볼륨 이미지의 공통점이 적을수록 더 많은 공간이 사용됩니다.
또한 WIM 형식에는 이 형식을 이전 버전의 Windows에 사용할 수 없도록 하는 어떠한 요소도 설계되지 않았다는 점을 강조하고 싶습니다. 즉, WIM 형식은 Windows Vista에서와 마찬가지로 Windows 2000에서도 잘 작동합니다. 이제 이미지가 캡처되고 적용될 때 어떠한 일이 일어나는지를 좀 더 자세히 살펴보겠습니다.

이미지 캡처
볼륨 이미지가 캡처될 때 수행되는 작업은 다음과 같습니다.
볼륨 메타데이터 캡처 ImageX가 볼륨 전체에 걸쳐 파일 이름, NTFS ACL 및 기타 파일 시스템 특성에 관한 데이터를 수집합니다. 스크립트 파일을 사용하여 특정 파일은 제외할 수도 있습니다.
파일 데이터 캡처 ImageX가 파일을 로드합니다. 각 파일이 볼륨에 로드되고 파일에 관한 특정 데이터를 수집할 준비가 됩니다.
파일 해시 생성 파일 자체를 기준으로 파일 암호화 해시가 생성됩니다. 이 해시는 이미지에서 파일의 고유 식별자가 됩니다.
중복 파일 확인 및 제거 해시가 동일한 다른 파일이 이미지에 이미 있으면 동일한 파일로 간주되고 새 파일은 이미 있는 파일을 가리켜 참조됩니다.
고유 파일 데이터 압축 CAB나 다른 여러 보관 형식과는 달리 WIM 파일의 각 파일은 파일 모음이 하나의 데이터 스트림으로 그룹화되어 압축되는 것이 아니라 개별적으로 압축됩니다. 압축을 하지 않도록 선택할 수도 있으며, 이 경우 이 단계를 건너뜁니다.
볼륨 메타데이터 압축 및 저장 모든 파일이 보관되면 볼륨에 대한 메타데이터 항목이 만들어집니다. 이 항목에는 볼륨 이미지에 추가된 각 파일이 나열됩니다.
이미지 XML 데이터 생성 및 저장 캡처된 각 볼륨 이미지에 대한 참조입니다. 예를 들어 ImageX /info를 실행하면 이 XML 데이터가 표시됩니다.
캐시된 WIM 데이터 인덱스 작성 마지막으로 캐시된 데이터와 함께 마스터 데이터 인덱스가 작성됩니다. 이 인덱스는 전체 WIM에 대한 마스터 파일 테이블이며 해시당 한 개의 항목을 포함합니다.
WIM은 파일 단위로 만들어집니다. 또한 WIM 파일은 이미지에 추가하는 볼륨의 개수에 관계없이 하나만 사용됩니다.

이미지 오버로드
WIM 작업에 착수했을 때 이와 비슷한 솔루션을 개발하고 있던 팀이 많았습니다. 자동 배포 서비스 팀은 다른 고객 부문을 대상으로 한 이미징 솔루션을 개발하고 있었습니다. 이 팀이 취한 방법에는 매우 흥미로운 몇 가지 하위 수준의 구현 내용이 있었지만 이미징 엔진은 당시의 다른 엔진과 마찬가지로 섹터에 기반을 두고 있었습니다. Windows XP Embedded 팀 또한 IHV(독립 하드웨어 공급업체)가 시스템을 제조할 때 이미지를 배포할 수 있도록 섹터 기반 이미징 엔진을 만들었습니다. 그리고 2003년에 Microsoft가 Virtual PC 팀을 인수할 당시 이 팀은 VHD(가상 하드 디스크) 파일에 사용할 또 다른 파일 형식을 보유한 상태였습니다.
이러한 모든 형식은 근본적으로 섹터를 기반으로 합니다. 이러한 솔루션은 각각 해당 고객 부문의 요구 사항은 충족하지만 WIM에 대해 세웠던 우리의 기준을 충족하지는 못했습니다. 따라서 새로운 WIM 형식 개발과 이미지를 캡처하기 위한 ImageX 명령줄 도구를 만드는 작업을 계속하게 되었습니다. 결국에는 Windows Vista 베타 버전의 일부로 WIM이 공식적으로 발표되기 훨씬 전부터 다른 많은 다른 팀에서도 WIM 형식을 채택했습니다. 예를 들어 SMS 팀은 Operating System Deployment Feature Pack을 통해 WIM를 먼저 구현했습니다.

이미지 적용
이제 이미지 캡처와 반대되는 과정인 이미지 적용에 대해서 살펴보겠습니다.
캐시된 WIM 데이터 인덱스 로드 이 단계는 앞의 절차에 나오는 마지막 단계와 관련이 있습니다. 이 인덱스는 마스터 인덱스이므로 적용할 볼륨 이미지를 지정한 후 WIM에서 가장 먼저 로드되는 요소입니다.
이미지 메타데이터 검색 및 로드 ImageX가 각 볼륨 이미지와 관련된 메타데이터를 로드합니다.
디렉터리 구조 생성 모든 파일이 복원 위치를 가질 수 있도록 볼륨에 대한 전체 디렉터리 트리가 만들어집니다.
파일 데이터 추출 보관될 때와 정확하게 동일한 순서로 WIM에서 파일이 추출됩니다.
파일 데이터 적용 이 단계에서는 파일이 로드되고 압축이 해제된 다음(WIM에서 볼륨 이미지가 압축된 경우) 각각의 참조되는 위치로 복사됩니다. 마지막으로 각 파일의 메타데이터가 모두 적용됩니다.
모든 디렉터리 메타데이터 적용 디렉터리의 ACL로 인해 이미지가 올바르게 적용되지 않을 가능성이 있으므로 이 단계가 마지막 단계라는 점은 매우 중요합니다.

융통성 있는 압축
WIM 이미징 형식을 통해 제공하려고 한 주요 목표 중 하나는 융통성 있는 압축 옵션을 제공하는 것이었습니다. 따라서 필요한 경우 압축을 하여 볼륨 이미지를 캡처하고 원하지 않으면 압축을 하지 않고 이미지를 캡처할 수도 있게 만들었습니다. 압축을 하지 않는 옵션은 이미지를 굳이 압축할 필요가 없거나 고속 캡처가 중요한 경우에 사용하면 좋습니다.
압축과 관련해서 주의해야 할 몇 가지 사항이 있습니다. 압축은 항상 압축을 해제할 때보다 시간이 오래 걸립니다. 압축 알고리즘이 복잡할수록 주어진 데이터 집합을 압축하는 데 걸리는 시간도 길어집니다. 또한 압축 알고리즘에 제공하는 데이터가 많을수록 압축 성능이 우수해집니다.
WIM 이미지는 XPress 또는 LZX 압축을 통해 압축할 수 있으며 필요에 따라 압축을 하지 않을 수도 있습니다. XPress는 압축이 필요하기는 하지만 캡처 프로세스에 너무 많은 시간을 사용하고 싶지 않을 때 적절한 방법입니다. LZX는 최적의 압축 비율을 제공하지만 시간이 상당히 소요됩니다.
압축을 하지 않을 경우 이미지 캡처 속도는 가장 빠르지만 이미지 크기는 가장 커집니다. 압축 형식은 WIM 단위로 선택할 수 있습니다. 한 볼륨 이미지를 WIM에 캡처한 후에는 향후 모든 볼륨 이미지를 동일한 압축 설정을 사용하여 캡처해야 합니다.
WIM 이미지는 압축을 파일 단위로 수행하므로 압축이 완벽하지 않을 수 있습니다. 이에 대해서는 미리 알고 있었지만 이미지 편집을 보다 쉽게 수행할 수 있도록 내린 결정이었습니다. 캡처가 끝난 후에 이미지를 편집할 수 있는 기능은 매우 중요한 것입니다. 이미지를 캡처한 후 파일을 편집하려면 파일 데이터와 해당 메타데이터를 대체해야 합니다. 전체 WIM을 모두 한 번에 압축했다면 파일 편집을 지원하는 기능을 엔지니어링하기가 너무 복잡했을 것이고 이미지의 파일을 대체하는 데 너무 많은 시간이 소요될 것입니다. Windows 배포 팀에서는 절충된 방법을 마련하여 압축 성능이 우수할 뿐만 아니라 팀에서 만든 도구로 편집도 가능한 형식을 개발할 수 있었습니다.
이 칼럼을 통해 Windows Vista용으로 설계된 이미징 기능이 어떻게 작동하는지 잘 이해하셨으리라고 믿습니다. 다음 칼럼에서는 ImageX와 Windows 배포 서비스에 대해 자세히 살펴보고 WIM 이미지를 관리하고 배포하는 데 사용할 수 있는 몇 가지 도구를 소개하도록 하겠습니다.

Wes Miller는 텍사스 오스틴에 있는 Pluck(www.pluck.com)의 개발 관리자입니다. 이전에는 오스틴에 있는 Winternals Software에서 근무했으며 Microsoft에서 프로그램 관리자 및 Windows 제품 관리자로도 근무한 경력이 있습니다. 문의 사항이 있으신 분은 technet@getwired.com으로 연락하시기 바랍니다. Wes는 이번 칼럼을 작성하는 데 도움을 주었으며 현재 Microsoft의 WIM/ImageX 프로그램 관리자인 John Macintyre에게 감사의 뜻을 전했습니다.


 Windows Confidential: RunOnce 대기
Windows Confidential
RunOnce 대기
Raymond Chen

프로세스 진행 도중 시스템을 다시 시작해야 하는 설치 작업을 한다고 생각해 보십시오. 예를 들어 해당 프로그램을 설치하려면 현재 사용하고 있는 시스템 DLL을 업그레이드해야 합니다. 새 DLL 파일을 설치하려면 시스템을 다시 시작해야 합니다. 시스템이 다시 시작되어 DLL이 업그레이드되면 설치 과정의 다음 단계에서 해당 DLL 파일을 사용할 수 있습니다.
RunOnce 키는 이처럼 시스템이 다시 시작된 후에 설치 프로그램이 설치를 마치기 위해 사용하도록 고안된 기능입니다. 이는 프로그램이 문제를 일으키지 않는다고 믿을 때 얘기입니다.
Windows® Explorer에서는 데스크톱 및 작업 표시줄을 생성하기 전에 RunOnce 프로그램이 실행되어 완료될 때까지 대기합니다. 이는 RunOnce가 설치 프로그램용이라는 원리에 의해 작동하기 때문입니다. RunOnce 프로그램을 사용하면 시스템 구성 데이터가 변경될 수 있으므로 사용자는 재구성되고 있는 시스템을 사용하지 않아야 합니다.
예를 들어 RunOnce 프로그램에서 방금 설치된 파일의 기준을 새로 설정하고 바인딩하며 이 중 일부는 셸 확장에 포함된 파일이라고 생각해 보겠습니다. 이 경우 사용자는 업데이트 도중에 해당 프로그램을 실행하거나 확장 프로그램을 활성화하지 않아야 합니다.
"설치 프로그램용" 원리에 숨은 또 다른 함정은 RunOnce 키는 사용자가 관리자 권한으로 로그온하는 경우에만 실행된다는 점입니다. 그러므로 관리자가 아닌 사용자의 경우에는 설치를 완료할 수 없습니다. 또한 관리자가 아닌 사용자가 RunOnce 키를 실행하는 경우 더 이상 "한 번만 실행" 기능을 사용할 수 없습니다. 바로 이 점이 문제를 야기하는 것입니다. "한 번 실행했으니까 그만 실행하면 안 될까?"라고 생각할 수도 있지만 이러한 시스템의 전역 상태를 변경하려면 관리자 권한이 있어야 합니다. 그러나 관리자가 아닌 사용자는 당연히 사용자 권한을 가질 수가 없겠지요. 프로그램은 "한 번만 실행"되지 않으며 대신 "관리자가 로그온할 때까지 계속해서 실행"됩니다.

(더 작게 보려면 이미지를 클릭하십시오.)

(더 크게 보려면 이미지를 클릭하십시오.)
프로그램 설치 마무리 과정에 사용되는 RunOnce는 Windows 설치 시 자동으로 확인됩니다. 서비스 팩을 설치하거나 새로운 버전의 Windows로 업그레이드할 경우 설치 마법사에서 RunOnce 키를 확인합니다. RunOnce 키를 확인하면 "Hey, you still have some unfinished program installation in progress. Please finish that before you try to upgrade the operating system."(일부 프로그램 설치 과정이 완료되지 않았습니다. 운영 체제를 업그레이드하기 전에 설치를 완료하십시오.)와 같은 오류 메시지가 표시됩니다. 이는 프로그램 설치 도중에 운영 체제가 변경되지 않도록 하기 위한 올바른 기능입니다.
RunOnce에 대해 자세히 살펴보면 이전의 상황을 알 수 있습니다. RunOnce는 관리자 및 관리자가 아닌 사용자의 구분이 없었던 Windows 95 운영 체제에 처음 포함되었던 기능입니다. Windows 95에서는 모든 사용자가 관리자였으므로 RunOnce를 사용하는 설치 프로그램은 다음에 시스템을 다시 시작할 때 RunOnce 작업이 수행될 것임을 확신할 수 있었습니다.
Windows Vista™와 같은 최신 Windows 운영 시스템에서는 관리자 권한이 없는 사용자의 경우 몇 개월에 한 번씩 로그온할 수 있습니다. 결과적으로 RunOnce를 실행해야 하는 프로그램은 대기 시간이 매우 길어질 수 있습니다.
조금 다른 이야기를 해보자면, 계속 실행되는 RunOnce를 본 적이 있습니다. 이 RunOnce는 실행될 때마다 RunOnce 키에 자신을 다시 추가합니다. 이 경우 더 이상 프로그램 설치의 일부가 아닌 프로그램의 정상적인 작업의 일부로 실행되므로 분명 RunOnce 키의 용도와 다르게 실행되는 것입니다. 또한 이러한 동작으로 인해 Windows 설치 프로그램은 실행될 때마다 메시지를 표시합니다.
이 성가신 프로그램은 "I just need to do a few more little things and I'll really be done."(몇몇 사소한 작업을 실행해야 하며 이 작업은 금방 완료됩니다.) 또는 "The program will not finish installing today, but surely tomorrow."(프로그램 설치는 오늘 안으로 끝나지 않지만 내일은 반드시 완료됩니다.)와 같은 메시지를 계속해서 표시하므로 사용자는 결국 운영 체제를 업그레이드할 수 없게 됩니다. 이건 마치 오지도 않을 '고도'를 기다리는 사무엘 베케트의 희곡과 조금도 다르지 않은 상황이라고 할 수 있겠군요.

Raymond Chen은 자신이 운영하는 웹 사이트인 The Old New Thing(영문)에 Windows의 역사와 Win32 프로그래밍에 대한 글을 게시하고 있습니다. 또한 그는 현재 자신의 웹 사이트와 같은 제목의 저서인 The Old New Thing(Addison-Wesley, 2006)의 출간을 준비하고 있습니다.