 TechNet Magazine December 2007

TechNet Magazine December 2007

Communications: Exchange Server 2007 서비스 팩 1의 16가지 새로운 기능

일반적인 서비스 팩과 달리 Exchange Server 2007 서비스 팩 1은 핫픽스와 보안 업데이트 이상의 많은 기능을 제공합니다. 이 문서에서는 SP1에서 제공하는 새로운 기능 중 중요하게 여겨지는 것을 몇 가지 소개합니다.

Tony Smith Communications: Exchange Server 2007 서비스 팩 1의 대기 연속 복제

서비스 팩 1에서 제공하는 가장 흥미로운 기능 중 하나는 대기 연속 복제입니다. 이 기능을 사용하여 작동 시간을 개선하고, 데이터 손실을 줄이며, 전자 메일 유지 관리 및 보관 업무를 간편하게 만드는 방법을 알아보십시오.

Scott Schnoll Communications: Windows Server 2008에서 Exchange 실행

Windows Server 2008에서 Exchange를 실행할 준비가 되었습니까? Microsoft Exchange 개발 팀에서도 이 작업을 수행했으며 Paul Bowden이 이 과정에서 얻은 경험을 공유하고 유용한 정보를 제공합니다.

Paul Bowden Communications: Exchange Server 2007을 사용한 통합 메시징 배포

음성 메일, 팩스 기능, 전자 메일 메시징을 하나의 사서함에 결합하는 것은 매우 어려운 작업처럼 보일 수 있지만 생각보다 쉽습니다. 이 문서에서는 조직에 통합 메시징을 배포하는 방법을 설명합니다.

Jeff Goodwin Security: 기본 컴퓨터 범죄 조사 가이드

컴퓨터 범죄 조사를 쉽고 저렴하게 수행할 수 있는 방법에 대해 알아봅니다. 관리자는 기본적인 조사에 이를 활용할 수 있습니다.

Tom Cloward and Frank Simorjay Networking: Microsoft Security Intelligence Report(보안 정보 보고서)

Microsoft는 컴퓨터 사용자가 직면하는 보안 위협에 대한 방대한 데이터를 수집하고 있습니다. 이를 통해 Microsoft는 최근에 발생한 위협의 추세, 다양한 Windows 버전이 위협에 반응하는 양상, 그리고 전 세계에서 위협의 영향을 가장 많이 받는 지역 등을 파악합니다.

Tim Rains Networking: 원인을 파악하기 힘든 네트워크 문제 추적

뚜렷한 이유도 없이 한 시스템이 다른 시스템과 통신이 되지 않을 수 있습니다. 이 문서에서 제공하는 팁은 이러한 문제를 신속하게 진단하고 복구할 수 있도록 지원합니다.

Christopher Stoneff From the Editor: 대화를 시작합시다!

Joshua Hoffman Letters: 독자의 목소리

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

Greg Steen SQL Q&A: 메모리 구성, 성능 프로파일링, 채우기 비율 설정 및 기타 정보

Edited by Nancy Michell Utility Spotlight: Microsoft Security Assessment Tool

무료로 제공되는 이 유틸리티와 전자 설문지를 통해 중간 규모 조직에서 네트워크 보안 관련 위험을 파악하고 이를 해결할 수 있습니다.

Lance Whitney The Cable Guy: 네트워크 정책 서버

Windows Server 2008의 NPS(네트워크 정책 서버) 서비스는 Windows Server 2003에서 사용되는 인터넷 인증 서비스를 대체하며, 시스템 상태 요구 사항 적용에서 관리 기능 향상에 이르는 수많은 사항을 개선했습니다.

Joseph Davies Windows PowerShell: 자세히 알아보기

Windows PowerShell에서는 무심코 보아 넘기기 쉬운 많은 기능을 제공합니다. 방법론적 접근법으로 Windows PowerShell cmdlet에 접근하면 미처 몰랐던 여러 가지 강력한 기능을 찾아낼 수 있습니다.

Don Jones Hey, Scripting Guy!: WinRM의 귀환

집사가 일을 제대로 했습니까? 물건이 창고에 촛대와 함께 잘 있습니까? 여기서는 이러한 질문에는 답변해 드리지 않습니다. 하지만 WinRM 시리즈 2부작과 함께 Scripting Guy가 드디어 4주 만에 돌아왔습니다.

The Microsoft Scripting Guys Security Watch: Windows 도메인 암호 정책

지금까지 Windows에서는 도메인별로 하나의 암호 정책만 허용되었습니다. 그러나 Windows Server 2008에서는 관리자가 여러 암호 정책을 구현할 수 있어 다양한 유형의 사용자에 맞게 각기 다른 정책을 적용할 수 있습니다.

Derek Melber The Desktop Files: 가상 세계에서의 Windows 배포

가상화에 대해 생각하고 계십니까? 아니라면 꼭 생각해보셔야 합니다. 가상 시스템 배포를 위해서는 무엇을 알아야 하는지, 피해야 할 것은 무엇인지, 가상화는 어떻게 작동하는지 이번 기사를 통해 확인하시기 바랍니다.

Wes Miller Field Notes: 바뀔 수 있는 미래

사생활에서 사용하는 기술 및 그에 대한 인식이 직업 생활에서의 기술 및 인식과 융합되면서 IT는 '소비자 주도(consumerized)'로 되고 있습니다. 그리고 그것이 직업 생활과 개인 생활에 모두에 깊은 영향을 미치고 있습니다.

Romi Mahajan Windows Confidential: 조이스틱은 전자레인지가 아니다.

DirectInput 힘 피드백 조이스틱 인터페이스의 주기적 힘 지정 방법과 예기치 못한 결과에 관해 논의합니다.

Raymond Chen


 Communications: Exchange Server 2007 서비스 팩 1의 16가지 새로운 기능
Communications Tony Smith

Exchange Server 2007 서비스 팩 1의 16가지 새로운 기능
한 눈에 보기:
  • 새로운 관리 기능
  • 향상된 서버 역할
  • 향상된 통합 메시징

대부분의 관리자는 서비스 팩을 다운로드하여 서버 및 데스크톱 시스템에 적용하는 프로세스에 대해 잘 알고 있습니다. 이러한 다운로드는 시스템을 최신 상태로 유지할 수 있도록
핫픽스와 보안 업데이트를 제공합니다. 서비스 팩에 이러한 핫픽스와 보안 업데이트 이상의 기능이 포함될 수도 있습니다. 곧 제공될 Microsoft® Exchange Server 2007 서비스 팩 1이 바로 그렇습니다. 이 서비스 팩에는 많은 새로운 기능이 포함되어 있습니다.
이 다운로드(go.microsoft.com/fwlink/?LinkId=91472에서 제공될 예정)를 사용하면 Exchange Server 2007 전체 설치(모든 SP1 업데이트 포함)와 기존 Exchange Server 2007 설치에 대한 업데이트를 모두 수행할 수 있습니다. Exchange Server 2007 SP1은 Windows Server® 2003 SP1, SP2 및 R2에 설치할 수 있으며 향후 출시될 Windows Server 2008과의 호환성도 지원합니다.
서비스 팩 1의 새로운 기능과 향상된 기능은 짧은 이 문서에서는 모두 다룰 수 없을 정도로 굉장히 많습니다. 이 문서에서는 사용자의 Exchange 환경을 개선하는 데 사용할 수 있는 가장 주목할 만한 변경 내용만 일부 살펴보겠습니다. 모든 변경 내용에 대해 자세히 알아보려면 "Exchange Server 2007 SP1의 새로운 기능"(technet.microsoft.com/bb676323.aspx)을 참조하십시오.

Exchange 관리 콘솔의 변경 내용
서비스 팩 1에서는 Exchange 관리 콘솔에 몇 가지 유용한 기능이 새로 추가되었습니다(그림 1 참조). 그 중에서도 Exchange Server 2007과 함께 기본적으로 설치되는 진단, 문제 해결 및 복구 도구 모음을 제공하는 도구 상자에 이제 공용 폴더 관리 콘솔, 템플릿 세부 정보 편집기 및 라우팅 로그 뷰어가 새로 추가되었습니다.
그림 1 서비스 팩 1이 설치된 Exchange 정책 관리 콘솔
그림 1 서비스 팩 1이 설치된 Exchange 정책 관리 콘솔
이제 Exchange 관리 콘솔, 공용 폴더 관리 콘솔, 템플릿 세부 정보 편집기 및 큐 뷰어를 사용하여 결과 창과 작업 창에서 목록을 내보낼 수 있습니다. 목록은 텍스트(탭으로 구분), 텍스트(쉼표로 구분), 유니코드 텍스트(탭으로 구분) 및 유니코드 텍스트(쉼표로 구분) 형식으로 내보낼 수 있습니다. 이제 Exchange 관리 콘솔만이 아니라 공용 폴더 관리 콘솔, 템플릿 세부 정보 편집기 및 큐 뷰어에서 결과 창을 필터링할 수 있습니다.
가장 주목할 만한 점은 앞에서 언급한 공용 폴더 관리 콘솔과 같은 새로운 관리 인터페이스가 Exchange 관리 콘솔에 다수 포함되어 있다는 것입니다 이러한 관리 인터페이스는 이 문서에서 별도로 설명합니다.

IPv6 지원
Windows Server 2008에 대한 지원을 통해 이제 IPv6(인터넷 프로토콜 버전 6)이 지원됩니다. IPv6 지원을 사용하려면 IPv4 및 IPv6 프로토콜 스택을 모두 사용하도록 설정된 Windows Server 2008에 Exchange Server 2007을 설치해야 합니다. 설치하기 전에 IPv4를 사용하지 않도록 설정하면 Exchange에서 IPv6이 지원되지 않습니다.
IPv4 또는 IPv6 형식으로 IP 주소와 범위를 입력할 수 있습니다. 한 가지 서버 역할을 제외한 모든 서버 역할은 IPv6 주소를 사용하는 장치, 서버 및 클라이언트와 데이터를 주고받을 수 있습니다. 예외적인 한 가지 서버 역할은 바로 통합 메시징 서버 역할입니다. 필수적으로 사용되는 몇몇 전화 통신 및 음성 구성 요소의 제한으로 인해 통합 메시징 역할에는 IPv4를 사용해야 합니다.

POP3 및 IMAP4 관리 UI
Exchange 관리 콘솔에 POP3 및 IMAP4 관리를 위한 새로운 관리 UI가 추가되었습니다. 이 관리 UI에서 포트 설정, 인증 설정, 연결 설정을 비롯하여 클라이언트 액세스 서버의 POP3 및 IMAP4에 대한 모든 설정을 구성할 수 있습니다. 그림 2에서는 IMAP4 속성 구성 대화 상자를 보여 주며 같은 옵션을 POP3에도 사용할 수 있습니다.
그림 2 POP3/IMAP4를 위한 Exchange 관리 콘솔
그림 2 POP3/IMAP4를 위한 Exchange 관리 콘솔

더욱 강력해진 사서함 관리
Exchange 관리 콘솔의 사서함 관리 기능은 이제 기존 사용자 계정에 대한 일괄 사서함 만들기를 지원합니다. 또한 관리자는 새 마법사를 사용하여 사서함에 대해 모든 권한을 부여하거나 제거할 수 있으며 사서함에 대해 다른 사람으로 보내기 권한을 구성할 수 있습니다.

사서함 데이터 관리를 위한 새로운 기능
이제 관리자가 사서함 데이터 관리를 위해 .pst 파일을 가져오고 내보낼 수 있습니다. Exchange 관리 셸에서 Import-Mailbox와 Export-Mailbox cmdlet을 각각 사용하여 가져오기와 내보내기 작업을 수행할 수도 있습니다.
Exchange Standard 클라이언트 액세스 라이선스가 있는 Exchange 서버에 상주하는 관리되는 기본 폴더에 MRM(메시징 레코드 관리)을 적용할 수 있습니다. 관리되는 사용자 지정 폴더에 MRM을 적용하려면 Exchange Enterprise 클라이언트 액세스 라이선스가 있어야 합니다. Set-Mailbox cmdlet에 새로 추가된 RemoveManagedFolderAndPolicy 매개 변수를 사용하면 사서함에서 MRM 정책을 제거하고, 사서함에 적용된 MRM 정책의 일부로 만들어진 모든 관리되는 폴더에서 MRM 속성을 제거하고, 관리되는 폴더를 표준 폴더로 변환할 수 있습니다.
새로 추가된 성능 모니터 카운터를 통해 온라인 조각 모음이 마지막으로 실행된 시기, 조각 모음이 완료되는 데 소요된 시간, 조각 모음에서 수행한 작업 등 온라인 조각 모음에 관한 다양한 정보를 모니터링할 수 있습니다. 이 정보를 통해 온라인 조각 모음 간격을 최적화할 수 있습니다.

원격 지우기 확인
Exchange Server 2007에서는 관리자나 계정 사용자가 원격 지우기 명령을 실행하여 모바일 장치에서 모든 사용자 데이터를 지울 수 있습니다. 이 보안 기능은 모바일 장치를 분실하거나 도난당한 경우에 유용하게 사용할 수 있습니다. 더 나아가 서비스 팩 1에서는 장치가 원격 지우기 요청을 승인하면 요청한 사용자에게 확인 메시지가 전송되는 기능을 제공합니다. 사용자가 Outlook® Web Access나 OWA를 통해 요청한 경우에는 사용자가 확인 전자 메일을 받으며, 관리자가 Exchange 관리 콘솔을 통해 요청한 경우에는 관리자와 사용자가 모두 확인 전자 메일을 받습니다.

더욱 강력해진 OWA 클라이언트
이 웹 기반 전자 메일 클라이언트는 모바일 작업자에게 더 나은 메시징 환경을 제공하는 많은 향상된 기능을 제공합니다. SP1에서는 OWA 사용자가 개인 메일 그룹과 서버 쪽 규칙을 만들고 편집할 수 있습니다. 또한 휴지통 및 지운 편지함 복구 기능을 사용할 수 있습니다.
이동 및 복사 명령이 UI에 추가되어 이제 폴더 목록을 마우스 오른쪽 단추로 클릭하면 표시되는 메뉴를 통해 폴더를 이동하고 복사할 수 있습니다. 항목 목록을 마우스 오른쪽 단추로 클릭하거나 도구 모음에서 아이콘을 클릭하여 메시지 폴더나 공용 폴더의 개별 항목을 이동하거나 복사할 수도 있습니다.
또한 OWA 사용자는 /public 가상 디렉터리를 사용할 필요 없이 공용 폴더에 모든 권한으로 액세스할 수 있으며 이를 지원하기 위해 Exchange 2003 백 엔드 서버를 사용할 필요도 없습니다. OWA에서 공용 폴더 검색 기능도 지원됩니다.
이제 S/MIME 기능을 통해 서명 및 암호화된 전자 메일 메시지를 읽고 작성할 수 있습니다(그림 3 참조). CNG(Cryptography API: Next Generation) 지원 및 Suite-B 규정 준수도 포함됩니다. 또한 OWA UI를 사용자 지정하여 사용자 지정 응용 프로그램을 완벽하게 통합할 수 있습니다.
그림 3 S/MIME 메시지 설정
그림 3 S/MIME 메시지 설정

OWA Light의 작성 모니터링
거의 모든 웹 브라우저에서 사용할 수 있도록 설계된 OWA의 단순화된 버전인 Outlook Web Access Light는 이제 사용자가 모든 종류의 긴 항목(예: 메시지 또는 일정 항목)을 작성하는 동안 작업을 모니터링함으로써 사용자가 입력을 하는 동안에는 세션이 제한 시간을 초과하지 않도록 하여 데이터 손실을 방지합니다. 또한 메시지 작성 양식이 열려 있는 상태로 작업이 진행되지 않아 세션 제한 시간이 초과되는 경우에는 메시지가 자동으로 임시 보관함에 저장됩니다.

향상된 직접 올리기 성능
직접 올리기는 모바일 장치와 Exchange 2007 서버 간에 HTTPS 연결을 설정하면 작동합니다. Exchange 2007 SP1에서는 HTTPS 요청 및 응답 헤더의 크기가 줄었으며 이로 인해 모바일 장치에서 보내고 받는 데이터의 양이 줄었습니다.

공용 폴더 관리
이제 그림 4에서 볼 수 있는 새로운 공용 폴더 관리 콘솔을 통해 관리자가 Exchange 관리 콘솔에서 공용 폴더를 만들고 구성하고 관리할 수 있습니다. 주소 목록, 전자 메일 주소 정책, 동적 메일 그룹, 메일 그룹은 공용 폴더를 인식합니다. 따라서 주소 목록, 전자 메일 주소 정책, 동적 메일 그룹 및 메일 그룹 받는 사람을 미리 볼 때 그룹 구성원 조건에 포함되는 메일 사용 가능 공용 폴더를 볼 수 있습니다.
그림 4 공용 폴더 관리 콘솔
그림 4 공용 폴더 관리 콘솔
Exchange 2007 SP1의 공용 폴더 관리 콘솔을 사용하여 공용 폴더 관리 권한을 구성할 수 있습니다. 이 작업은 Add-ExchangeAdministrator cmdlet 또는 Exchange 관리자 추가 마법사를 사용하여 공용 폴더 관리 역할에 사용자를 추가하거나 Add-PublicFolderAdministratorPermission cmdlet을 사용하여 공용 폴더에 특정 권한을 부여하거나 거부하는 방법으로 수행할 수 있습니다.

향상된 메시지 처리 및 라우팅
Active Directory® 포리스트 내에 배포된 허브 전송 서버는 조직 내의 모든 메일 흐름을 처리하고, 전송 규칙과 저널 규칙을 적용하고, 받는 사람 사서함에 메시지를 배달합니다. 허브 전송 서버는 인터넷으로 전송된 메시지를 네트워크 경계의 Edge 전송 서버에 릴레이합니다. SP1에는 이러한 서버 역할에 대한 향상된 기능이 포함되어 있습니다.
Exchange Server 2007에는 백 프레셔라는 시스템 리소스 모니터링 기능이 포함되어 있으며 이 기능을 통해 허브 및 Edge 전송 서버는 높은 리소스 사용량에 대처할 수 있습니다. SP1에서는 사용 가능한 디스크 공간 요구 사항이 4GB에서 500MB로 대폭 줄었습니다.
SP1의 Exchange 관리 콘솔은 추가 전송 구성 설정을 제공합니다. 이제 X.400 주소 공간을 신뢰할 수 있는 도메인으로 구성할 수 있게 되어 X.400 긴 주소 공간이 지원됩니다.
이제 허브 전송 서버에서 우선 순위 큐를 지원합니다. Outlook 사용자가 메시지에 할당한 메시지 우선 순위는 이제 분류기에 의해 처리됩니다. 이를 통해 높은 중요도 설정으로 보내진 메시지가 우선적으로 처리되어 낮은 중요도 설정의 메시지보다 빨리 배달됩니다.
Exchange 2007 SP1에서는 Exchange 관리 셸 cmdlet에 IsScopedConnector 매개 변수가 추가되고 Exchange 관리 콘솔에 Scoped Send Connector(범위가 지정된 송신 커넥터) 확인란이 추가되어 단일 Active Directory 사이트에 대한 전송 커넥터의 범위 지정이 단순해졌습니다. 송신 커넥터의 범위가 지정될 때 송신 커넥터의 원본 서버와 동일한 Active Directory 사이트에 있는 허브 전송 서버만 라우팅 결정에서 송신 커넥터로 간주됩니다.

향상된 Edge 전송 서버 동기화 기능
Exchange Server 2007 SP1에서는 Start-EdgeSynchronization cmdlet을 사용하여 Active Directory에서 ADAM(Active Directory Application Mode) 디렉터리 서비스로의 데이터 동기화를 즉시 시작할 수 있습니다. Exchange 2007 SP1에서는 이 cmdlet에 Server 매개 변수가 지원되므로 원격 컴퓨터에서 이 cmdlet을 실행할 수 있습니다.
Edge 전송 서버의 동기화 상태에 대해 보고하는 진단 cmdlet인 Test-EdgeSynchronization cmdlet은 개별 사용자에 대해 동기화 결과를 확인하는 데 사용할 수 있는 새로운 매개 변수 집합으로 보완되었습니다.

TransportConfig 개체 복제
복제된 구성 스크립트를 통해 관리자는 두 개 이상의 Edge 전송 서버를 환경에 배포할 때 일관된 구성을 적용할 수 있습니다. SP1에서는 Edge 전송 서버 역할에 대해 서버 전체의 설정을 제어하는 TransportConfig 개체가 복제된 구성 정보에 포함됩니다. 이 개체가 포함됨으로써 서버 배포, 백업 및 복원 절차가 대폭 간소화되었습니다.

향상된 통합 메시징 기능
초기 Exchange Server 2007 릴리스에서 통합 메시징은 매우 흥미로운 기능이었습니다. 서비스 팩 1에는 이 기능을 기반으로 하는 많은 새로운 기능과 향상된 기능이 도입되었습니다. 일부 기능은 Active Directory 포리스트에 Office Communications Server 2007을 배포해야 사용할 수 있지만 Office Communications Server 없이도 사용할 수 있는 기능이 많습니다. 이 문서에서 통합 메시징에 대한 변경 내용을 모두 다룰 수는 없으므로 몇 가지 주목할 만한 추가 기능만 살펴보겠습니다. 통합 메시징에 대한 자세한 내용을 알고 싶다면 TechNet Magazine 이번 호에서 "Exchange Server 2007을 사용한 통합 메시징 배포"를 읽어 보십시오.
먼저 Office Communications Server 2007이 있어야 사용할 수 있는 몇 가지 새로운 기능부터 살펴보겠습니다. 이제 미디어 스트림의 방화벽 통과와 Hi-Fi(high-fidelity) 음성 메시지가 지원됩니다. 대상에서 호출 전달을 사용하는 경우 음성 메시지를 남길 때 전달에 대해 알림을 받을 수 있습니다. 사용자는 PIN을 입력하지 않고도 Office Communicator 2007에서 Outlook Voice Access에 액세스할 수 있습니다. Office Communicator 2007에서는 부재 중 호출 알림 전자 메일 메시지와 음성 메시지 알림이 통합되었습니다(그림 5 참조). 이외에도 많은 새로운 기능이 있습니다.
그림 5 Office Communicator의 음성 메일 알림
그림 5 Office Communicator의 음성 메일 알림
Office Communications Server 없이도 사용할 수 있는 향상된 통합 메시징 기능 중 하나는 SRTP(Secure Realtime Transport Protocol) 지원입니다. 초기 Exchange Server 2007 릴리스에서는 보안되지 않음과 보안이라는 두 가지 보안 모드를 제공합니다. 보안 모드에서는 SIP(Session Initiation Protocol) 트래픽만 암호화되고 RTP 트래픽은 암호화되지 않습니다. SP1에서는 보안되지 않음, SIP 보안 및 보안이라는 세 가지 보안 모드를 제공합니다. SIP 보안 모드에서는 SIP 트래픽만 암호화되고 RTP 트래픽은 암호화되지 않습니다. 보안 모드에서는 SIP와 RTP 트래픽이 모두 암호화됩니다. Exchange 관리 콘솔을 사용하여 다이얼 플랜에 대해 MTLS(Mutual Transport Layer Security)를 구성할 수도 있습니다.
또 다른 변경된 기능으로는 통합 메시징 사용 마법사가 있습니다. 이 마법사를 사용하면 사용자에 대해 SIP 또는 E.164 주소를 추가할 수 있습니다. SP1에서는 Exchange 관리 콘솔을 사용하여 다이얼 플랜에 대한 URI 유형을 구성하고, DiffServ를 사용한 QoS(서비스 품질) 지원을 통해 미디어 트래픽에 우선 순위를 지정하는 기능도 추가되었습니다.

향상된 고가용성
서비스 팩 1에서는 고가용성을 개선하는 몇 가지 새로운 기능과 함께 기존의 고가용성 기능도 많은 부분 향상되었습니다. 새로운 기능과 향상된 기능은 Exchange 2007 서버 역할의 데이터 및 서비스 사용 가능성을 확보할 수 있도록 하는 기존의 시나리오를 확장합니다. 새로운 시나리오에서는 조직이 고가용성 시나리오를 사이트 복구 시나리오에서 분리하여 조직의 특수한 요구에 맞는 구성을 개별 영역에 배포할 수 있습니다.
무엇보다도 Windows Server 2008에 대한 추가된 지원을 통해 복수 서브넷 장애 조치(failover) 클러스터와 새로운 쿼럼 모델 지원 기능(디스크 및 파일 공유 감시)을 사용할 수 있게 되었습니다. 연속 복제 환경을 사전 모니터링하기 위한 추가 기능을 비롯하여 클러스터 보고 및 모니터링 기능도 효율적으로 향상되었습니다. 저장소 그룹의 수동 복사본을 포함하는 디스크의 I/O가 감소했으며, 로그 파일 복사가 빨라졌고, 클러스터된 사서함 서버 노드 간에 이동이 신속해지는 등 성능도 향상되었습니다.
마지막으로, 관리 및 구성 작업을 간편하게 수행할 수 있도록 하는 마법사가 새롭게 추가되었으며(그림 6 참조) 클러스터된 사서함 서버 탭, 클러스터 연속 복제(CCR) 구성 페이지와 같은 클러스터된 메일 사서함 관리를 위한 UI 컨트롤이 새롭게 추가되었습니다.
그림 6 Manage Clustered Mailbox Server Wizard(클러스터된 사서함 서버 관리 마법사)
그림 6 Manage Clustered Mailbox Server Wizard(클러스터된 사서함 서버 관리 마법사)

대기 연속 복제
SCR(대기 연속 복제)은 LCR(로컬 연속 복제)과 CCR에서 사용하는 것과 같은 로그 전달 및 재생 기술을 사용하여 추가적인 배포 옵션과 구성을 제공합니다. SCR은 LCR 및 CCR과 비슷하지만 나름의 고유한 특성을 지니고 있습니다. SCR에 대한 자세한 내용을 보려면 TechNet Magazine 이번 호에서 "Exchange Server 2007 서비스 팩 1의 대기 연속 복제"를 참조하십시오.

결론
Exchange Server 2007 서비스 팩 1은 분명히 핫픽스와 보안 업데이트 그 이상을 제공합니다. Exchange Server 2007 서비스 팩 1은 앞으로 널리 사용될 많은 새로운 기능과 향상된 기능을 제공합니다. 이 문서에서는 지면 부족으로 새로운 기능과 향상된 기능을 모두 다루지 못했지만 이 문서를 통해 새로운 기능에 대해 개략적으로 파악할 수 있었기를 바랍니다. 서비스 팩 1의 모든 변경 내용에 대한 정보와 다운로드, 웹캐스트 및 토론 포럼을 보려면 Exchange Server TechCenter(technet.microsoft.com/exchange)를 참조하십시오.

Tony Smith는 Exchange User Education 팀의 수석 테크니컬 라이터로, 통합 메시징 관련 작업을 전문적으로 수행하고 있습니다. Microsoft에서 근무하기 전에는 네트워크 엔지니어, Microsoft 공급자 및 Microsoft Certified Trainer로 활동했습니다. 이외에도 서적 및 실습용 매뉴얼을 비롯하여 Microsoft Learning을 위한 몇몇 콘텐츠 작성 프로젝트에 참여했습니다.
© 2007 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..


 Communications: Exchange Server 2007 서비스 팩 1의 대기 연속 복제
Communications Scott Schnoll

Exchange Server 2007 서비스 팩 1의 대기 연속 복제
한 눈에 보기:
  • 대기 연속 복제 구성
  • 중복성의 중요성
  • SCR로 가동 중지 시간을 줄이는 방법

서비스 팩 1은 Exchange 2007에 몇 가지 새로운 기능과 향상된 기능을 제공합니다. 이러한 기능 중에서 SCR(대기 연속 복제)은 조직에 데이터 센터 내 중복성과 사이트 복구 기능을 모두 제공하도록 설계되었습니다. 이름이 암시하듯이 SCR은
대기 복구 서버를 사용하거나 사용할 수 있도록 지원하는 시나리오를 위해 설계되었습니다.
Exchange 2007 RTM(Release To Manufacturing) 버전을 사용해 본 적이 있다면 Exchange 2007이 로그 전달 기능과 Windows® 장애 조치(failover) 클러스터 지원을 통해 데이터 센터 내 중복성과 사이트 복구 기능 또한 제공한다는 사실을 잘 알고 계실 것입니다. RTM 버전에서는 로그 전달, 즉 연속 복제를 그림 1에 나오는 LCR(로컬 연속 복제)과 그림 2에 나오는 CCR(클러스터 연속 복제)의 두 가지 형태로 사용할 수 있습니다.
그림 1 로컬 연속 복제
그림 1 로컬 연속 복제
그림 2 Windows 장애 조치(failover) 클러스터의 두 번째 서버에 로그를 전달하는 CCR
그림 2 Windows 장애 조치(failover) 클러스터의 두 번째 서버에 로그를 전달하는 CCR
연속 복제는 관리자가 각 사서함 데이터베이스의 보조 복사본을 온라인으로 사용 및 유지 관리할 수 있도록 지원함으로써 데이터 가용성과 중복성을 제공합니다. 이 데이터베이스 복사본은 프로덕션 데이터베이스의 오류, 손실 또는 손상에 대비한 최전방 방어선입니다. 이 경우 데이터 복원을 위해 백업 테이프를 찾느라 시간을 낭비하는 대신 데이터베이스 복사본을 활성화하여 단 몇 분 내에 프로덕션 데이터베이스로 전환할 수 있습니다.
SCR은 조직 환경에서 데이터 및 서비스 가용성을 제공하는 기존의 시나리오를 확장합니다. 새로운 시나리오에서는 고가용성 토폴로지와 사이트 복구 토폴로지를 분리할 수 있으며 조직 내 각 영역의 특정 필요에 맞게 조정된 구성을 배포할 수 있습니다.
Exchange 2007 RTM 버전에서는 데이터 센터 내 중복성과 사이트 복구 기능을 제공하지만 LCR과 CCR은 각 데이터베이스에 대해 여분의 복사본을 하나만 제공하므로 복구 기능과 중복성 중에서 하나를 선택해야 합니다. 예를 들어 CCR이 제공하는 데이터 및 서비스 가용성 기능을 고려해 보십시오. 단일 데이터 센터에 액티브 노드와 패시브 노드를 모두 배포할 경우 두 노드가 같은 물리적 사이트에 있으므로 데이터 센터 내 데이터 및 서비스 가용성은 제공되지만 사이트 복구 기능은 제공되지 않습니다. 반면 액티브 노드를 한 데이터 센터에 배포하고 패시브 노드를 보조 데이터 센터에 배포할 경우 데이터 및 서비스 가용성을 제공하는 패시브 노드가 보조 데이터 센터에 있으므로 사이트 복구 기능만 제공되고 데이터 센터 내 가용성은 제공되지 않습니다.
서비스 팩 1의 SCR을 사용하면 각 데이터베이스의 추가 복사본을 만들 수 있어서 고가용성과 사이트 복구 기능이라는 두 가지 목적을 모두 달성할 수 있습니다. 예를 들어 그림 3에서 볼 수 있듯이 주 데이터 센터에서 로컬로 저장소 그룹을 복제하고(고가용성을 위해 CCR 사용), 보조 또는 백업 데이터 센터에서 원격으로 저장소 그룹을 복제하기 위해(사이트 복구 기능을 위해 SCR 사용) SCR과 CCR을 모두 사용할 수 있습니다. 보조 데이터 센터에는 사이트 복구 시나리오에서 클러스터된 대체 사서함 서버를 사용하여 활성화하고 신속하게 제공할 수 있는 대기 클러스터가 포함됩니다.
그림 3 레드먼드 데이터 센터에 배포된 CCR 및 퀸시 데이터 센터에 배포된 SCR
그림 3 레드먼드 데이터 센터에 배포된 CCR 및 퀸시 데이터 센터에 배포된 SCR
그림 3에서는 각각 고유의 Active Directory® 사이트가 있는 레드먼드와 퀸시라는 두 데이터 센터가 포함된 기업 배포를 보여 줍니다. 레드먼드 사이트는 주(프로덕션) 데이터 센터에 있고 퀸시 사이트는 보조(백업) 데이터 센터에 있습니다. 레드먼드에는 데이터 센터 내 중복성을 제공하기 위해 CCR이 배포되었습니다. 퀸시에는 사이트 복구 기능을 위해 Exchange 2007에 필요한 인프라 요소와 함께 대기 클러스터에 SCR 대상이 구성되었습니다. 클라이언트 액세스와 허브 전송 서버, Active Directory와 DNS 서버, 인터넷 액세스 등의 추가 인프라 요소는 전용 리소스일 수도 있고 비전용 리소스일 수도 있습니다. 전용 리소스는 데이터 센터에 상주하는 데이터 센터 사용자만 지원하도록 지정된 리소스입니다. 비전용 리소스는 로컬 데이터 센터의 사용자와 함께 다른 위치의 사용자도 지원하는 리소스입니다. 조직의 필요에 맞게 리소스를 전용으로 사용할지 비전용으로 사용할지를 결정해야 합니다. 전용 및 비전용 리소스에 대한 자세한 내용은 Exchange Server 2007 도움말 항목 "Site Resilience Configurations"(technet.microsoft.com/bb201662.aspx)를 참조하십시오. 새로운 유형의 MNS(주 노드 집합) 쿼럼 사용도 유의해서 보십시오. Exchange Server 2007에서는 CCR이 기존의 Voter 노드 대신 FSW(파일 공유 감시) 기능이 있는 MNS 쿼럼을 사용합니다(그림 3 참조).
그림 4의 복구 기능을 염두에 두고 설계된 CCR/SCR 환경은 EXCLUS1 서버에서 호스팅되는 사서함과 서비스에 여러 계층의 중복성을 제공함으로써 작은 규모의 오류는 물론 큰 규모의 치명적 오류로부터 사서함을 보호합니다.
그림 4 SCR을 사용하여 저장소 그룹 간을 복제하는 &#xA;독립 실행형 사서함 서버
그림 4 SCR을 사용하여 저장소 그룹 간을 복제하는 &#xA;독립 실행형 사서함 서버
소규모 및 중간 규모 조직에서도 SCR을 사용함으로써 혜택을 얻을 수 있습니다. 예를 들어 그림 4에서 볼 수 있듯이 조직에서 두 개의 독립 실행형 사서함 서버(EXMBX1과 EXMBX2)를 배포한 다음 SCR을 사용하여 한 사서함 서버에서 다른 사서함 서버로 저장소 그룹 일부 또는 모두를 복제할 수 있습니다.
이 예에서 EXMBX1과 EXMBX2는 둘 다 다섯 개의 활성 저장소 그룹이 있는 프로덕션 서버입니다. 각 저장소 그룹은 SCR 원본이고 해당 SCR 대상은 다른 서버에 있습니다. 저장소에 오류가 발생하거나 SCR 원본으로 구성된 활성 저장소 그룹을 사용할 수 없는 다른 상황이 발생할 경우 Exchange 관리 셸의 몇 가지 관리 작업을 사용하여 SCR 대상 복사본을 신속하게 활성화할 수 있습니다. Microsoft® Office Outlook® 2007과 Exchange 2007의 데이터베이스 이식 및 자동 검색 기능을 사용하면 활성 저장소 그룹(또는 드물지만 여러 개의 활성 저장소 그룹)이 손실될 경우 가동 중지 시간을 단 몇 분으로 최소화할 수 있습니다.

SCR 원본 및 대상
LCR 및 CCR과 마찬가지로 SCR에서도 저장소 그룹의 활성 복사본 및 수동 복사본 개념을 사용합니다. 하지만 SCR에서는 활성과 수동 복사본이 각각 SCR 원본과 대상을 의미합니다. 물론, SCR 원본과 대상은 저장소 그룹 복사본입니다. SCR에서는 복구 저장소 그룹을 사용하도록 설정할 수 없습니다.
SCR의 시작점(SCR 원본)은 독립 실행형 사서함 서버의 저장소 그룹이거나 단일 복사본 클러스터 또는 CCR 환경에서는 클러스터된 사서함 서버의 저장소 그룹입니다. 클러스터된 사서함 서버를 SCR 원본으로 사용할 수는 있지만 SCR 자체는 클러스터된 솔루션이 아니므로 Windows 클러스터 서비스는 필요하지 않습니다. SCR의 끝점(SCR 대상)은 독립 실행형 사서함 서버이거나 사서함 역할은 설치되어 있지만 클러스터된 사서함 서버는 구성되어 있지 않은 장애 조치(failover) 클러스터의 노드입니다.

원본과 대상의 관계
각 SCR 원본 저장소 그룹에는 여러 SCR 대상이 있을 수 있습니다. 예를 들어 원본에 원본과 같은 데이터 센터에 있는 첫 번째 대상과 원본과 다른 데이터 센터에 있는 두 번째 대상이 있을 수 있습니다. 하지만 원본당 대상을 5개 이상은 사용하지 않는 것이 좋습니다. 대상을 5개 이상 사용하려는 경우 SCR 원본 서버의 메모리, CPU 및 디스크 리소스가 받는 영향을 평가하여 이에 맞게 계획을 수립해야 합니다. 각 SCR 대상 컴퓨터는 여러 개의 원본 서버를 둘 수 있습니다. 원본과 대상 컴퓨터는 모두 Exchange 2007 서비스 팩 1을 실행해야 합니다. OS는 Windows Server® 2008이나 Windows Server 2003 SP2 등 Exchange 2007 서비스 팩 1에서 지원하는 버전 중 하나를 사용해야 합니다. 하지만 사용하는 운영 체제에 관계없이 SCR은 OS를 교차 지원하지 않으므로 SCR 원본의 운영 체제와 원본의 모든 SCR 대상에서 사용하는 운영 체제가 일치해야 합니다. 따라서 SCR 원본에서 Windows Server 2003을 실행하면 해당 원본의 모든 SCR 대상에서도 Windows Server 2003을 실행해야 합니다.
SCR은 Exchange 2007 Standard Edition에서 사용할 수 있습니다. SCC 또는 CCR 환경의 클러스터된 사서함 서버를 SCR 원본으로 사용하는 경우에는 Exchange 2007 Enterprise Edition이 있어야 합니다. 각 SCR 대상에서 지원하는 최대 인스턴스 수는 Enterprise Edition을 사용하는 경우 50개(50개의 복제된 저장소 그룹)이고, Standard Edition을 사용하는 경우 5개입니다.
SCR 대상에도 만족해야 하는 요구 사항이 있습니다. 첫째, 원본과 대상 컴퓨터가 같은 Active Directory 도메인에 있어야 합니다. Active Directory 사이트는 달라도 됩니다. 둘째, SCR을 통해 복제되는 각 저장소 그룹에 대해 원본과 해당하는 모든 대상의 데이터베이스 및 로그 파일 경로가 일치해야 합니다. 마지막으로, 노드나 서버가 SCR 대상으로 구성되어 있으면 SCR 대상 컴퓨터의 저장소 그룹에 LCR을 사용하도록 설정할 수 없으며 클러스터된 사서함 서버를 대기 장애 조치(failover) 클러스터에 추가할 수 없습니다.

SCR과 CCR 및 LCR 비교
그림 5에서 볼 수 있듯이 SCR은 LCR 및 CCR에서 사용하는 것과 같은 로그 전달 및 재생 기술을 사용하여 새로운 배포 옵션과 구성을 제공합니다. LCR 및 CCR과 마찬가지로 SCR을 사용하도록 설정한 저장소 그룹에는 데이터베이스가 둘 이상 포함될 수 없습니다. 또한 Exchange 조직에 공용 폴더 데이터베이스가 둘 이상 있는 경우 공용 폴더 데이터베이스에 SCR을 사용할 수 없습니다.
그림 5 장애 조치(failover) 클러스터의 다른 서버 또는 패시브 노드에 &#xA;로그를 전달하는 SCR
그림 5 장애 조치(failover) 클러스터의 다른 서버 또는 패시브 노드에 &#xA;로그를 전달하는 SCR
한 가지 큰 차이점은 SCR은 저장소 그룹당 여러 대상을 지원하지만 LCR과 CCR은 대상(수동 복사본)을 하나만 지원한다는 것입니다. 또 다른 큰 차이점은 CCR 및 LCR과는 달리 SCR 복사본은 백업할 수 없다는 것입니다. SCR을 사용하는 경우, SCR 원본 저장소 그룹에 대해 지원되는 백업을 수행하면 SCR 대상의 데이터베이스 헤더가 업데이트되고 로그 파일이 잘립니다. CCR 및 LCR을 사용하는 경우에는 SCR 원본 저장소 그룹의 활성 또는 수동 복사본에 대해 백업을 수행할 때 SCR 대상의 데이터베이스 헤더가 업데이트되고 로그 파일이 잘립니다.
LCR 및 CCR과 마찬가지로 SCR의 로그 전달은 연속적이며 끌어오기 모델을 사용합니다. 새 로그 파일이 닫히고 이 파일의 이름이 다음 생성 시퀀스 로그 파일 번호로 지정되면 곧바로 SCR 대상 컴퓨터에서 실행되는 Microsoft Exchange Replication Service가 SCR 원본 컴퓨터에서 닫힌 트랜잭션 로그 파일을 끌어와 검사하고 유효성을 확인한 다음 이를 SCR 대상 컴퓨터의 대응되는 저장소 그룹 로그 파일 폴더로 이동합니다.

재생 지연 시간
로그 파일이 SCR 대상 컴퓨터로 복사된 후 SCR은 LCR과 CCR이 하지 않는 작업을 수행합니다. SCR은 로그 파일을 데이터베이스 복사본에 곧바로 재생하지 않습니다. 대신 SCR은 50개 로그 파일을 24시간 동안 재생 지연하는 기본 제공 재생 지연 기능을 실행합니다. 기본 제공되는 지연 시간에 추가 지연 시간을 지정할 수도 있습니다. 재생 작업 지연은 다양한 시나리오에서 유용합니다. 예를 들어 활성 데이터베이스에 논리적인 손상이 발생할 경우 지연 기능을 통해 SCR 대상 데이터베이스의 논리적인 손상을 막을 수 있습니다.
관리자는 ReplayLagTime이라는 매개 변수를 통해 재생 지연 시간을 설정할 수 있습니다. 이 매개 변수는 Exchange 복제 서비스가 SCR 대상 컴퓨터로 복사된 로그 파일을 재생하기 전에 대기해야 할 시간을 지정합니다. 형식은 일.시간:분:초이고, 기본값은 24시간입니다. 설정할 수 있는 최대값은 7일이고, 최소값은 0초입니다. 값을 0초로 설정하면 50개 로그 파일에 대한 기본 지연 외에는 로그 재생 작업이 지연되지 않습니다.
ReplayLagTime 외에도 Exchange에는 ReplayLagTime 값에 관계없이 50개 로그 파일의 재생을 지연하는 기본 제공 지연 기능이 하드코드되어 있습니다. Exchange에서는 ReplayLagTime 또는 x개 로그 파일(여기서 x=50임) 중 더 큰 값을 기준으로 로그 파일 재생 시기를 결정합니다. 이는 연속 복제를 사용하는 SCR 원본(예: CCR 환경의 클러스터된 사서함 서버)에서 장애 조치(failover)가 발생하여 Restore-StorageGroupCopy cmdlet을 사용하여 하나 이상의 저장소 그룹을 온라인으로 전환해야 하는 경우에 저장소 그룹을 다시 시드할 필요가 없도록 추가적인 안전망 역할을 합니다. 시드는 ESE(Extensible Storage Engine) 스트리밍 백업 API를 사용하여 SCR 대상 컴퓨터에 SCR 원본 데이터베이스의 온라인 복사본을 만드는 프로세스입니다. SCR 대상에 대한 재생 작업을 지연하면 SCR 원본에 대한 손실 장애 조치(failover)가 발생하는 경우 SCR 원본에 대한 데이터 손실 특성상 두 개의 복사본이 시간상 서로 근접하게 되므로 SCR 복사본을 다시 시드해야 하는 경우가 최소화됩니다.

자르기 지연 시간
Exchange 2007 RTM 버전에서는 연속 복제 환경에서 로그 파일이 백업되고 데이터베이스 복사본에 재생된 후에야 로그 파일을 삭제할 수 있는 규칙이 적용됩니다. SCR을 사용할 때는 이 규칙이 수정됩니다. 여러 데이터베이스 복사본의 개념이 도입된 SCR에서는 로그 파일이 모든 SCR 대상 컴퓨터에서 검색되는 즉시 SCR 원본 컴퓨터에서 잘릴 수 있습니다. SCR 대상 복사본의 로그 재생 지연 시간이 길게 구성될 수 있으므로 SCR 원본 서버에서 로그 자르기 작업은 모든 로그가 모든 SCR 대상으로 재생될 때까지 기다리지 않습니다.
TruncationLagTime이라는 새 매개 변수를 사용하여 로그 자르기에 대해 추가 지연을 설정할 수도 있습니다. 이 매개 변수를 사용하면 SCR 대상 컴퓨터에 복사되어 데이터베이스 복사본에 재생된 로그 파일을 Exchange 복제 서비스가 자르기 전에 대기해야 할 시간(일.시:분:초 형식)을 지정할 수 있습니다. 이 시간은 로그 파일이 데이터베이스 복사본에 성공적으로 재생된 후 즉시 시작됩니다. 최대값은 7일이고, 최소값은 0초입니다. 값을 0초로 설정하면 로그 자르기 작업이 지연되지 않습니다.
SCR 환경에서는 백그라운드 스레드가 3분마다 실행되어 잘라야 할 로그 파일이 있는지 여부를 확인합니다. 로그 파일 생성 시퀀스가 저장소 그룹에 대한 로그 파일 검사점 이전이고 로그 파일이 ReplayLagTime과 TruncationLagTime을 더한 것보다 오래되었으면 SCR 대상의 로그 파일이 잘립니다.
SCR로 확장된 LCR 또는 CCR 환경에서는 로그 파일이 백업되었고, 로그 파일 생성 시퀀스가 저장소 그룹에 대한 로그 파일 검사점 이전이고, 저장소 그룹의 수동 복사본이 로그 파일이 잘릴 수 있는 상태에 있고, 모든 SCR 대상에서 로그 파일을 검사한 경우의 네 가지 조건을 모두 충족할 때 SCR 대상의 로그 파일이 잘립니다.

SCR 설정 및 관리
SCR은 Exchange 관리 셸의 Enable-StorageGroupCopy cmdlet을 통해 사용하도록 설정할 수 있습니다. SP1에서는 이 cmdlet에 몇 가지 새로운 매개 변수가 추가되었습니다. 앞에서 설명한 것처럼 ReplayLagTime과 TruncationLagTime을 사용하여 SCR 대상의 일부 동작을 제어할 수 있습니다. SeedingPostponed라는 또 다른 매개 변수를 사용하면 SCR 대상의 초기 시드 작업을 건너뛸 수 있습니다. 시드 지연은 다양한 상황에서 유용합니다. 예를 들어 SCR을 사용하도록 설정할 저장소 그룹의 데이터베이스가 100GB라고 가정해 보십시오. 시스템 사용량이 많은 프로덕션 시간대에 100GB나 되는 데이터를 네트워크를 통해 전송하고 싶지는 않을 것입니다. 이때 SeedingPostponed 매개 변수를 사용하면 SCR은 곧바로 사용할 수 있도록 설정하되 시드 작업은 나중에 수행할 수 있습니다. 나중에 준비가 되면 Update-StorageGroupCopy cmdlet을 사용하여 수동으로 SCR 대상을 시드할 수 있습니다.
위에서 언급한 매개 변수는 선택적이지만 Enable-StorageGroupCopy의 StandbyMachine 매개 변수는 SCR을 사용하는 데 반드시 필요합니다. 이 매개 변수는 SCR 대상이 포함될 컴퓨터의 이름을 지정합니다. 이 매개 변수의 값은 SCR을 사용하도록 설정하는 저장소 그룹의 msExchStandbyCopyMachines 특성 값의 일부로 설정됩니다. msExchStandbyCopyMachines 특성은 Exchange 2007 SP1이 Exchange 조직에 설치될 때 Active Directory 스키마에 추가되는 다중 값 유니코드 문자열입니다. SP1을 사용하려면 Active Directory의 스키마 업데이트가 필요한 것도 바로 이러한 이유 때문입니다.
StandbyMachine 매개 변수는 SCR을 사용하는 데 있어서 중요한 매개 변수이며, SCR 대상을 사용하도록 설정하고 관리하는 데 이 매개 변수를 사용하도록 SP1에서 몇 가지 cmdlet이 업데이트되었습니다. 그림 6에서는 업데이트된 cmdlet에 대해 설명합니다.
Figure 6 StandbyMachine 매개 변수를 사용하는 Cmdlet (Close Figure 6)

Cmdlet | 설명
Disable-StorageGroupCopy | 저장소 그룹에 대해 SCR 대상을 사용하지 않도록 설정합니다.
Get-StorageGroupCopyStatus | SCR 대상의 현재 상태를 확인합니다.
New-StorageGroup | Enable-StorageGroupCopy cmdlet을 사용하여 SCR을 사용하도록 별도로 설정할 필요 없이 새 SCR 사용 가능 저장소 그룹을 만듭니다.
Restore-StorageGroupCopy | SCR을 사용하지 않도록 설정하고 복구 절차의 일부로 Mount-Database 작업을 사용하여 SCR 대상 데이터베이스를 탑재 가능한 상태로 만듭니다.
Resume-StorageGroupCopy | SCR이 일시 중단된 저장소 그룹에 대해 연속 복제를 다시 시작하는 데 사용됩니다.
Suspend-StorageGroupCopy | SCR을 사용하도록 설정된 저장소 그룹에 대해 연속 복제 작업을 일시 중단합니다.
Update-StorageGroupCopy | SCR 대상 저장소 그룹을 시드하거나 다시 시드하는 데 사용됩니다.

SCR 대상 활성화
SCR에서는 원본 데이터가 손실되거나 사용할 수 없게 되면 사용할 수 있는 데이터의 최신 복사본을 하나 이상 제공합니다. SCR 대상 복사본을 가져와 프로덕션 데이터베이스로 다시 제공하는 프로세스를 활성화라고 합니다. 활성화는 복구 프로세스의 일부로 수행되며 데이터베이스 이식 또는 두 가지 설치 복구 옵션(독립 실행형 서버 복구의 경우 /m:RecoverServer, 클러스터된 사서함 서버 복구의 경우 /RecoverCMS) 중 한 가지 형태로 이루어집니다.

SCR 사용 방법
가상의 한 회사에서 SCR과 데이터베이스 이식을 통해 사서함 데이터베이스 오류가 발생했을 때 데이터베이스를 복구하는 방법을 살펴보겠습니다. 프로덕션 데이터베이스가 손상되었음을 발견한 후 관리자가 데이터베이스 이식을 통해 SCR 대상 데이터베이스를 활성화합니다.
이 조직에서는 Exchange 2007 SP1을 배포했으며 SCR을 사용하여 원격 사서함 서버에 저장소 그룹의 복사본을 제공하기로 결정했습니다. 원본과 대상 사서함 서버는 모두 같은 Active Directory 사이트에 있고 Active Directory 통합 DNS 서버를 사용하도록 구성되었습니다. Active Directory 복제 간격은 15분으로 구성되었습니다.

SCR 설정 및 복구 준비
MBX1이라는 단일 데이터베이스가 포함된 SG1이라는 단일 저장소 그룹에 대해 트랜잭션 로그 파일을 복제하도록 SCR이 구성되었습니다. 저장소 그룹 파일과 데이터베이스 파일의 경로는 각각 C:\SG1과 C:\SG1\MBX1.EDB입니다. 이 예에서 EXMBX1은 SCR 원본이고, EXMBX2는 SCR 대상입니다. 원본과 대상은 다음과 같이 구성되었습니다.
Enable-StorageGroupCopy EXMBX1\SG1 -StandbyMachine EXMBX2
SCR을 사용하도록 설정한 후 Get-StorageGroupCopyStatus cmdlet을 사용하여 SG1에 대한 SCR의 상태를 확인했습니다.
Get-StorageGroupCopyStatus EXMBX1\SG1 -StandbyMachine EXMBX2
SCR 대상 활성화 프로세스 도중 시간을 절약하기 위해 EXMBX2는 데이터베이스 이식 작업의 일부로 사용될 SG1PORT라는 저장소 그룹과 MBX1PORT라는 데이터베이스로 미리 구성되었습니다. SG1PORT와 MBX1PORT는 SCR 대상의 저장소 그룹 및 데이터베이스 파일과 별개입니다. 따라서 SCR 대상 경로와 충돌하지 않는 임시 경로를 사용하여 SG1PORT 및 MBX1PORT에 대한 경로가 구성되었습니다. SG1PORT와 MBX1PORT는 데이터베이스 이식성 개체로만 사용되며 SG1PORT에 대한 실제 저장소 그룹과 데이터베이스 파일은 필요하지 않습니다. 이 때문에 관리자가 MBX1PORT를 분리하고 저장소 그룹의 모든 파일을 삭제합니다. 저장소 그룹과 데이터베이스 개체는 이후 복구 프로세스 중에 데이터베이스 이식에 사용되므로 Active Directory에 그대로 남겨 둡니다.

활성화 및 복구
SCR 원본 데이터베이스가 물리적으로 손상되었음을 나타내는 응용 프로그램 이벤트 로그 항목이 있습니다. SG1에 대해 SCR을 사용하도록 설정되어 있으므로 관리자는 SG1에 대한 SCR 대상 데이터베이스의 수동 활성화를 수행하고, 데이터베이스 이식을 통해 데이터의 가용성을 복원하기로 결정했습니다. SCR 대상 복사본의 활성화는 다음 cmdlet을 사용하여 SG1에서 MBX1을 분리하는 것으로 시작합니다.
Dismount-Database EXMBX1\SG1\MBX1
그러면 SCR 대상 데이터베이스가 탑재 가능한 상태가 되고 원래 MBX1에 있었던 사서함이 MBX1PORT로 이동됩니다.
SCR을 사용하지 않도록 설정하고 SCR 대상 데이터베이스를 탑재 가능한 상태로 만드는 프로세스에서는 Restore-StorageGroupCopy cmdlet을 실행하는 작업이 수행됩니다. 이 작업은 저장소 그룹의 데이터베이스를 탑재 가능으로 표시하고 저장소 그룹에 데이터베이스를 탑재하여 발생한 데이터 손실(있는 경우)에 대한 보고서를 제공합니다. 또한 저장소 그룹의 활성 복사본에 의해 생성된 모든 로그 파일이 수동 복사본의 저장소 그룹 파일 위치에 있는지 확인합니다. 누락된 로그 파일이 있으면 로그 파일을 복사하려고 시도합니다. SCR 대상 데이터베이스를 탑재 가능한 상태로 만들기 위해서는 다음 cmdlet을 사용합니다.
Restore-StorageGroupCopy EXMBX1\SG1 -StandbyMachine EXMBX2
이 예에서는 SCR 원본 저장소 그룹에서 로그 파일을 복사할 수 있습니다. SCR 원본 컴퓨터가 다운되는 등의 이유로 로그 파일을 사용할 수 없는 경우 Restore-StorageGroupCopy 작업에 Force 매개 변수를 추가해야 합니다. Restore-StorageGroupCopy는 누락된 로그 파일을 복사하기 위해 항상 SCR 원본에 연결하려고 하므로 이 매개 변수를 추가하지 않으면 SCR 원본을 사용할 수 없는 경우 Restore-StorageGroupCopy 작업이 실패하고 데이터베이스가 탑재 가능한 상태가 되지 않습니다. Force 매개 변수를 추가하면 Restore-StorageGroupCopy 작업에서 원본 파일을 사용할 수 없음을 인식하여 SCR 원본으로 연결을 시도하지 않고 SCR 대상 데이터베이스를 탑재 가능한 상태로 만듭니다.
Restore-StorageGroupCopy 명령이 완료되면 관리자는 데이터베이스가 완전하게 종료된 상태인지 확인해야 합니다. 데이터베이스가 부적절한 종료 상태에 있으면(technet.microsoft.com/aa996757.aspx 참조) 완전하게 종료된 상태로 만들어야 합니다. SCR 원본(EXMBX1\SG1) 및 데이터베이스 이식에 사용되는 SCR 대상(SG1PORT)의 저장소 그룹(EXMBX2\SG1PORT)에 대해 저장소 그룹의 로그 파일 접두사(예: E00 또는 E01)가 같을 경우 복구 모드에서 Eseutil을 실행할 필요가 없으며 마지막 데이터베이스 탑재 작업 중 복제된 모든 로그 파일이 재생된 후 데이터베이스가 완전하게 종료된 상태가 됩니다. 데이터베이스가 완전하게 종료된 상태가 되지 않으면 데이터베이스에 대해 Eseutil(Exchange Server Database Utilities) 복구 모드(Eseutil /r)를 실행해야 합니다.
데이터베이스가 완전하게 종료된 상태가 되면 저장소 그룹 파일 및 데이터베이스 파일의 새 위치로 Active Directory를 업데이트하는 두 개의 명령을 실행할 수 있습니다. 다음 두 명령은 SG1PORT 및 MBX1의 원래 경로를 준비된 저장소 그룹 및 데이터베이스(SG1PORT 및 MBX1PORT)의 경로로 변경합니다.
Move-StorageGroupPath EXMBX2\SG1PORT -SystemFolderPath C:\SG1 -LogFolderPath C:\SG1 –ConfigurationOnly

Move-DatabasePath EXMBX2\SG1PORT\MBX1PORT -EdbFilePath C:\SG1\MBX1PORT.EDB –ConfigurationOnly
Active Directory에서 해당 개체의 구성 설정만 업데이트되도록 위 명령에 –ConfigurationOnly 매개 변수를 반드시 포함해야 합니다. SCR에서 데이터를 이미 EXMBX2의 C:\SG1로 복제했으므로 데이터나 파일이 이동되지 않으며 그럴 필요도 없습니다.
다음 단계로 복원 작업 중 덮어쓸 수 있도록 데이터베이스(MBX1PORT)를 구성합니다. 이 작업은 Exchange 관리 콘솔의 데이터베이스 개체 속성에서 "복원 시 이 데이터베이스 덮어쓰기 가능" 설정 확인란을 선택하거나 Exchange 관리 셸에서 다음 명령을 사용하여 수행할 수 있습니다.
Set-MailboxDatabase EXMBX2\SG1PORT\MBX1PORT -AllowFileRestore:$true
덮어쓸 수 있도록 데이터베이스를 구성했으면 그 다음 단계로 다음 명령을 사용하여 데이터베이스를 탑재합니다.
Mount-Database EXMBX2\SG1PORT\MBX1PORT
데이터베이스를 탑재한 후에는 SCR 원본 데이터베이스(SG1\MBX1)의 사서함을 EXMBX2의 MBX1PORT를 가리키도록 이동해야 합니다. Get-Mailbox cmdlet을 실행하고 출력을 Move-Mailbox cmdlet으로 연결하기만 하면 됩니다. 이 프로세스 중에 Move-Mailbox cmdlet으로 연결된 Get-Mailbox cmdlet의 출력에 Exchange 시스템 수행자 및 시스템 사서함이 포함되지 않아야 합니다. 이러한 사서함 개체는 이동할 필요가 없으며 이동해서도 안 됩니다. 다음 명령을 실행하여 시스템 사서함을 제외한 모든 사용자 사서함을 이동합니다.
Get-Mailbox -Database EXMBX1\SG1\MBX1 |where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox| ExOleDbSystemMailbox)'}| Move-Mailbox -ConfigurationOnly -TargetDatabase EXMBX2\SG1PORT\MBX1PORT
이제 MBX1PORT에 대한 클라이언트 액세스가 가능합니다. 하지만 사용자가 EXMBX1\SG1\MBX1에서 EXMBX2\SG1PORT\MBX1PORT로 이동된 자신의 사서함에 실제로 액세스할 수 있는지 여부는 Active Directory 복제 지연에 따라 달라집니다. 즉, 디렉터리 서버의 수에 따라 업데이트가 환경 전체에 전파되는 데 다소 시간이 걸릴 수도 있습니다. 클라이언트 액세스 방법도 문제가 될 수 있습니다. Outlook 2007을 실행하는 메시징 클라이언트와 Outlook을 실행하지 않는 클라이언트는 사용자의 클라이언트 액세스 서버에서 사용하는 디렉터리 서버가 새 경로로 업데이트된 후 사용자 사서함에 액세스할 수 있습니다. Outlook 2003 및 이전 버전을 실행하는 메시징 클라이언트의 경우 사용자의 데스크톱 메시징 프로필이 새 서버 이름으로 업데이트되어야 합니다.

최종 단계
클라이언트가 사서함 및 사서함 데이터에 액세스할 수 있게 되면 마지막으로 SCR을 사용하도록 다시 설정하여 중복성이 제공되도록 해야 합니다. 이 작업은 EXMBX1에서 나머지 저장소 그룹과 데이터베이스 파일을 제거하여 수행할 수 있습니다. 파일을 제거하고 나면 EXMBX1\SG1\MBX1의 경로를 임시 위치로 이동하고 EXMBX1을 EXMBX2의 SCR 대상으로 만들 수 있습니다.

Scott SchnollMicrosoft Exchange Server 팀의 수석 테크니컬 라이터로, Exchange Server 2007에 대한 콘텐츠를 작성하고 있습니다. Microsoft에서 근무하기 전에는 Exchange Server 2003 Distilled(Addison-Wesley Professional, 2004)를 집필했으며 Exchange 2000 Server: The Complete Reference(McGraw-Hill/OsborneMedia, 2001)를 수석 저자로 집필했습니다.


 Communications: Windows Server 2008에서 Exchange 실행
Communications Paul Bowden

Windows Server 2008에서 Exchange 실행
한 눈에 보기:
  • Windows Server 2008에서 Exchange 설정
  • 구성 관련 유용한 팁
  • Exchange 환경 이해

Microsoft의 Exchange 개발 팀에서 필자의 업무는 팀의 일정, 반복적인 작업 및 우선 순위를 설정하는 것입니다. Microsoft에서는 이러한 업무를 수행하는 사람을 릴리스 관리자라고 합니다. 다른 회사의 기술 프로젝트 관리자와 비슷하다고 할 수 있습니다. 이 업무에 경험이 있는 사람이라면
누구나 알겠지만 좋은 제품을 제시간에 공급하려면 팀의 지식, 기술, 노력 및 배려가 필요합니다. 이러한 유능한 팀과 일할 때는 신뢰를 하루 아침에 얻을 수 없으며 꾸준히 쌓아가야 합니다.
자신의 노력을 입증하는 한 가지 방법은 Exchange의 시험판 버전을 실행하는 프로덕션 서버인 "개밥(dogfood)" 서버에 자신의 사서함을 실행하는 것입니다. 이 환경은 2-3주마다 새 Exchange 빌드로 업그레이드하는 유동적인 환경입니다. 이러한 설정을 통해 소프트웨어를 실제 사용자의 상호 작용이 있는 실제 환경에서 테스트할 수 있습니다. 필자의 팀은 최신 테스트 빌드에서 사서함을 실행하기도 합니다. 이때 제가 겪은 경험담을 이야기할까 합니다.

"Longhorn" 준비
2006년 말 Exchange Server 2007을 막 출시했을 때는 새로운 OS인 Windows Server®(코드 이름 "Longhorn")의 출시가 임박한 시점이었습니다. 새로운 Exchange 플랫폼의 첫 번째 서비스 팩에 대한 계획을 세우기 시작했을 때 Exchange와 Windows® 일정이 비슷하며 "Longhorn"(Windows Server 2008)이 크게 부각될 것임이 분명해졌습니다. 당시 필자의 팀은 Windows Server 2003과 Windows Server 2008 모두를 대상으로 Exchange Server 2007 SP1을 설계하기로 결정했습니다. 여러 버전의 Windows에서 사용하는 엔터프라이즈 응용 프로그램을 지원하려면 매우 많은 조정과 계획이 필요합니다. 예를 들어 Exchange는 IIS와 함께 작동하는 경우가 많은데 Windows Server 2008에는 새 버전인 IIS 7.0이 포함됩니다.
필자는 Windows Server 2008을 2006년 12월 말에 처음으로 테스트 환경에 설치한 것으로 기억합니다. 이날의 기억 중 두 가지가 잊혀지지 않습니다. 첫 번째는 설치가 매우 빨랐다는 점이고, 두 번째는 관리 도구가 Windows Server 2003과는 크게 달랐지만 매우 간편하게 사용할 수 있다는 점이었습니다.
필자의 기본 테스트 환경에서 Windows Server 2008은 Windows Server 2003 설치에 필요했던 시간의 1/3에 정도의 시간 내에 설치되었습니다. 그 이유 중 하나는 운영 체제 실행에 필수적이지 않은 선택적 구성 요소가 기본적으로 구성되지 않는다는 점입니다. 이는 컴퓨터의 보안 취약점을 최소화하고 구성을 최대한 단순화하는 데 상당히 도움이 됩니다. 불필요한 잡동사니를 원하는 사람은 없을 것입니다. 이러한 설치 방식의 일반적인 단점은 구성 요소를 추가하려고 할 때마다 디스크를 삽입해야 한다는 것입니다. 하지만 Windows Server 2008에서는 모든 파일이 SxS('사이드 바이 사이드'로 발음) 폴더에 복사됩니다. 그런 다음 서버 관리자 도구를 사용하여 필요한 구성 요소를 구성하면 운영 체제가 파일 복사 작업을 처리합니다.
이 단계에서 Server Core에 대해 잠깐 언급하겠습니다. Server Core는 최소한의 운영 체제 구성 요소만을 설치하는 Windows Server 2008의 설치 모드입니다. 이 모드에서는 탐색기도 설치되지 않으므로 일반적으로 명령 프롬프트를 통해 서버 콘솔과 상호 작용합니다. 이 모드는 도메인 컨트롤러, DNS 서버 등의 인프라 서버에 적합합니다. 하지만 이 모드에서는 실행할 수 없는 응용 프로그램 종류도 있습니다. Exchange에서는 관리 코드를 많이 사용하므로 Server Core 설치에서는 지원되지 않습니다.

Exchange 설정
필자는 Windows Server 2008 및 Exchange Server 2007 SP1의 실제 미디어를 사용하여 추가적인 다운로드나 필수 구성 요소 없이 처음부터 새로 시스템을 설치하는 편을 선호합니다. 설치한 Windows Server 2008을 Exchange에 맞게 구성하는 가장 좋은 방법은 ServerManagerCmd 도구를 사용하는 것입니다. 필자는 Windows Server 2008에 Exchange를 설치하고 실행하는 데 필요한 운영 체제 구성 요소만 설치하는 XML 응답 파일(그림 1)을 만들었습니다. 새 운영 체제를 설치한 후 이 명령을 실행하여 시스템을 설정합니다.
Figure 1 ServerManagerCmd answer file for Exchange (Close Figure 1)
<!-- Windows Server 2008과 호환되는 ServerManagerCmd 응답 파일        --> <!-- 사용 방법: ServerManagerCmd -ip Exchange.xml                                -->

<ServerManagerConfiguration Action="Install" xmlns="http://schemas.microsoft.com/sdm/Windows/ServerManager/Configuration/2007/1">

    <!-- 기본: PowerShell 1.0 기능 설치 --> <Feature Id="PowerShell"/>

    <!-- 스키마 준비: LDIFDE와 LDP 및 ADSIEdit 등의 다른 디렉터리 도구 설치 --> <Feature Id="RSAT-ADDS"/>

    <!-- CAS/MBX: 추가 자식 구성 요소와 함께 웹 서버 역할 설치 --> <Role Id="Web-Server"/> <RoleService Id="Web-Metabase"/> <RoleService Id="Web-Lgcy-Mgmt-Console"/> <RoleService Id="Web-Basic-Auth"/> <RoleService Id="Web-Windows-Auth"/>

    <!-- CAS: OWA용 세 가지 인증 유형, GZip 압축 및 외부에서 Outlook 사용 지원 설치 --> <RoleService Id="Web-ISAPI-Ext"/> <RoleService Id="Web-Digest-Auth"/> <RoleService Id="Web-Dyn-Compression"/> <Feature Id="RPC-over-HTTP-proxy"/>

    <!-- EDGE: Active Directory Lightweight Directory Services(이전의 ADAM) 설치 --> <Role Id="ADLDS"/>

    <!-- UM: Windows Media Player 구성 요소 설치 --> <Feature Id="Desktop-Experience"/>

</ServerManagerConfiguration>
참고: 프로그래머 주석은 예제 프로그램 파일에는 영문으로 제공되며 기사에는 이해를 돕기 위해 번역문으로 제공됩니다.
ServerManagerCmd –ip Exchange.xml
명령 실행 후 시스템을 다시 시작하면 사서함, 클라이언트 액세스, 허브 전송, Edge 전송 및 통합 메시징과 같은 Exchange 역할을 설치하는 데 필요한 모든 것이 갖추어집니다.
ServerManagerCmd에 –query 스위치를 사용하는 방법도 유용합니다. 이렇게 하면 역할과 서비스의 전체 목록이 열거되고 실제 구성이 표시됩니다(그림 2의 녹색 텍스트 참조).
Figure 2 Enumerating Exchange roles and services
Figure 2 Enumerating Exchange roles and services
이제 다시 본론으로 돌아가겠습니다. 필자의 팀은 2007년 초반 몇 개월을 Windows Server 2008에서 최대의 성능을 이끌어 내는 데 어떠한 변경이 필요한지 파악하면서 보냈습니다. 이 과정에서 한 가지 깨닫게 된 것은, 테스트 환경에 소프트웨어를 설치하고 지칠 때까지 극한의 테스트를 수행할 수도 있겠지만 정말로 중요한 것은 실제 사용자가 실제 배포 작업 시 겪게 되는 실제 품질 수준이라는 것입니다. 바로 이러한 이유 때문에 제품을 실제 환경의 일상적인 작업 방식대로 사용하면서 소위 "개밥" 테스트라고 하는 제품 테스트를 하는 것입니다. 2007년 4월의 Windows Server 2008 베타 3 릴리스는 이러한 테스트 단계를 넘어서 프로덕션 환경에 배포할 수 있는 전환점이 되었습니다.
Windows Server 2008에 Exchange 서버를 처음 배포할 때 필자는 운영 팀 구성원의 작업을 지켜보았습니다. Exchange 설치는 매끄럽게 진행되었고 서비스가 모두 정상적으로 실행되었습니다. 이제 사서함을 이동하고 실제로 정상 작동하는지 살펴보기만 하면 되었습니다. 필자는 이 일에 자원했습니다. 필자의 사서함은 2GB이었는데 26분 후 Windows Server 2008에서 Exchange를 통해 전자 메일을 보낼 수 있었습니다. 성공이었습니다.

교훈
Windows Server 2008에 처음 설치할 때부터 필자의 팀은 세부 조정을 수행했고 작업량이 많을 때도 문제가 없도록 준비했습니다. 이 과정에서 몇 가지 중요한 배포 관련 결정을 해야 했습니다.
설치 Exchange Server 2007 SP1은 원래의 Exchange Server 2007(필자는 Exchange 2007 RTM이라는 용어를 사용함) 설치에 대한 업그레이드로 사용할 수도 있고, 아무것도 설치되지 않은 컴퓨터를 준비하고 Exchange Server 2007 SP1 미디어를 사용하여 직접 설치할 수도 있습니다. Windows Server 2008을 실행하는 컴퓨터에는 Exchange Server 2007 RTM을 설치할 수 없기 때문에 이 사실은 중요합니다.
업그레이드 Windows Server 2003 SP2에서 Windows Server 2008로 운영 체제의 현재 위치 내 업그레이드를 수행할 수는 있지만 이 경우 먼저 제거해야 하는 몇 가지 구성 요소가 있습니다. 그 중 하나가 Windows PowerShell™입니다. 이것은 Exchange 관리의 핵심입니다. 게다가 Exchange 설치는 Windows PowerShell을 기반으로 합니다. 이러한 이유 때문에 Exchange가 이미 설치된 경우에는 운영 체제의 현재 위치 내 업그레이드를 지원할 수 없습니다. 따라서 대개의 경우 Windows Server 2008을 새 컴퓨터에 설치한 다음 Exchange Server 2007 SP1을 설치해야 합니다.
IPv6 Exchange는 Windows Server 2008의 몇 가지 새로운 기능을 사용하도록 설계되었습니다. 예를 들어 IPv6이 기본적으로 설치되며, 새 운영 체제에서 두 개의 Exchange 서버가 실행 중이면 자동으로 IPv6을 사용하여 서로 통신합니다. Exchange 관리 콘솔의 인터페이스에서도 IPv6 주소 범위가 지원됩니다. 그러나 한 가지 유의할 점이 있습니다. Exchange에서는 여전히 IPv4 주소가 각 네트워크 인터페이스에 바인딩되어 있어야 합니다.
읽기 전용 도메인 컨트롤러 Active Directory® 배포의 다소 근본적인 변화 중 하나는 읽기 전용 도메인 컨트롤러(또는 글로벌 카탈로그 서버)라는 개념입니다. 이를 통해 기업에서는 단방향 복제를 수신하며 변경 사항을 역방향 복제할 수 없는 Active Directory 서버를 배포할 수 있습니다. 따라서 물리적 보안을 보장할 수 없는 지사나 원격 사무실 환경에서는 이 기능이 유용할 수 있습니다. 하지만 Exchange Server 2007 SP1에서는 읽기 전용 도메인 컨트롤러를 사용할 수 없으며 Active Directory의 일반적인 쓰기 가능 파티션에 액세스할 수 있어야 합니다.

Exchange 환경
Exchange 및 Windows Server 리소스
  • Windows Server 2008 TechCenter
  • Exchange Server TechCenter
  • TechNet Evaluation Center
  • Windows Server 2008 가상 랩

배포에 적합한 운영 체제 수준을 선택해야 할 경우 그림 3과 같이 필요에 맞게 다양한 구성을 실행할 수 있습니다.
Figure 3 Exchange environment matrix (Close Figure 3)

Exchange 버전 | 서버 운영 체제 | 도메인 컨트롤러
Exchange Server 2007 SP1 | Windows Server 2008 | Windows Server 2008
Exchange Server 2007 SP1 | Windows Server 2008 | Windows Server 2003
Exchange Server 2007 SP1 | Windows Server 2003 SP2 | Windows Server 2008
Exchange Server 2007 SP1 | Windows Server 2003 SP2 | Windows Server 2003
고려해야 할 또 다른 사항은 버전이 혼합된 배포입니다. 상호 작용하는 혼합된 버전의 Exchange 및 Windows를 사용하는 경우가 많습니다. 예를 들어 Exchange Server 2007 SP1을 클라이언트 액세스 서버용 Windows Server 2008에 배포하고 Windows Server 2003 사서함 서버의 Exchange Server 2007 RTM에 액세스하도록 할 수 있습니다.
Exchange 이전 버전과 Windows Server 2008 Active Directory를 함께 사용할 때 알아야 할 내용이 있습니다. Exchange Server 2003 SP2 이상을 사용하는 경우에는 해당 환경에 Windows Server 2008 도메인 컨트롤러를 배포하고 사용할 수 있습니다. 하지만 아직 Exchange 2000을 사용하고 있는 경우에는 해당 Exchange 서버가 있는 Active Directory 사이트에 대한 Windows Server 2008 도메인 컨트롤러 배포를 보류하거나 Exchange 2000이 Windows Server 2008 도메인 컨트롤러를 사용하지 않도록 DSAccess(디렉터리 서비스 액세스) 설정을 하드코드할 수 있습니다.

결론
필자의 팀은 Exchange 2007 SP1이 Windows Server 2003과 Windows Server 2008 플랫폼 모두에서 제대로 작동하도록 하기 위해 많은 노력을 기울였습니다. Exchange에서 배포 유연성과 원활한 상호 작용 시나리오를 제공하기 위해 노력했습니다. Exchange를 Windows Server 2008에 배포할 때는 간편함과 빠른 속도에 놀랄 것이며 외부에서 Outlook 사용 클라이언트에 대한 우수한 클라이언트 액세스 서버 확장성과 같은 뛰어난 성능과 향상된 기능도 경험할 수 있을 것입니다.
Windows Server 2008은 향후 메시징 분야의 혁신을 가져올 플랫폼을 제공합니다. 틀림없이 만족하게 될 것입니다.

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


 Communications: Exchange Server 2007을 사용한 통합 메시징 배포
Communications Jeff Goodwin

Exchange Server 2007을 사용한 통합 메시징 배포
한 눈에 보기:
  • 전화 통신 기본 사항
  • 통합 메시징 설계 고려 사항
  • 사용자 마이그레이션

여러분은 조직 환경에 Exchange Server 2007 통합 메시징을 배포하기로 결정했습니다. 이에 따라 통합 메시징 서버 역할을 설치하고 이를 기존 PBX와 통합했습니다. 이제 여러분을 비롯하여 다른 10명의 직원에게 오는 음성 메일, 전자 메일 및 팩스 메시지가 Exchange에 저장됩니다. 이것으로
중요한 작업은 끝냈다고 생각할 수도 있습니다. 하지만 업무에 영향을 주지 않고 동일한 기능을 여러 사이트에 분산된 수천 명의 구독자에게 배포하려면 어떻게 해야 할까요?
이 문서의 내용이 이러한 작업에 도움이 된다면 좋겠습니다. 이 문서는 사용자 환경에 통합 메시징을 배포하는 방법을 이해하고 배포와 관련된 전화 통신의 개념을 쉽게 받아들일 수 있도록 작성되었습니다. Exchange Server 2007 통합 메시징의 설치, 구성 또는 기능과 관련하여 도움이 필요한 경우 이 문서의 뒷부분에 나오는 "통합 메시징 리소스" 추가 기사를 참조하십시오. 이 외에도 Microsoft는 고객에게 Exchange Server 2007 통합 메시징의 배포, 설계 및 상담 서비스를 제공할 수 있는 통합 메시징 전문 업체를 선별해 놓았습니다. 통합 메시징의 설치, 구성 또는 배포와 관련하여 도움이 필요한 경우 추가 기사에 나열된 전문 업체 중 한 곳에 문의하십시오.

시작
통합 메시징 기술이 Exchange에서 전혀 새로운 기술은 아닙니다. 많은 조직에서는 이미 Exchange와 통합되는 통합 메시징 제품을 제공하고 있습니다. 하지만 Exchange Server 2007은 통합 메시징을 기본적으로 지원하는 최초의 Exchange 버전입니다. 통합 메시징이 소개된 이후 많은 고객이 조직 내 소규모 그룹에 Exchange Server 2007 통합 메시징을 배포했습니다. 하지만 여러 가지 이유로 소규모 그룹을 제외한 다른 사용자에게는 통합 메시징을 배포하지 않았습니다. 가장 큰 이유는 대부분의 Exchange 관리자가 전화 통신의 개념이나 통합 메시징 서비스를 구현하는 데 필요한 기술에 익숙하지 않아서 이러한 솔루션을 설계하여 조직에 배포하는 데 많은 어려움을 겪고 있기 때문입니다.
다른 배포 프로젝트와 마찬가지로 단계별 접근 방법을 취하면 최선의 결과를 얻을 수 있습니다. 통합 메시징 프로젝트는 다섯 단계로 진행되어야 합니다. 여기에는 아키텍처 계획, 솔루션 테스트, 사용자 커뮤니티 파일럿 테스트, 교육, 새 시스템으로 사용자 마이그레이션이 있습니다. 프로젝트를 계획할 때 조직의 IT 그룹과 전화 통신 그룹이 모두 참여하도록 하는 것이 중요합니다.
사용자가 기존의 음성 메일 플랫폼에서 일상적으로 사용하던 여러 기능을 통합 메시징에 복제해야 하며, 이것이 가능하지 않은 경우에는 대체 솔루션을 설계하여 새 시스템 구현 시 사용자가 받을 영향을 최소화해야 합니다. 이것이 바로 전화 통신 팀에서 지원해야 할 핵심 영역입니다. 이와 동시에 전화 통신 팀은 배포 작업이 시작될 때 새 음성 메일 플랫폼을 관리 및 지원하고 관련 문제를 해결하는 데 필요한 사항을 IT 팀을 통해 습득해야 합니다.

전화 통신 기본 사항
통합 메시징의 기본 아키텍처, 호출 흐름 및 관련 용어를 이해하면 계획을 수립하기가 훨씬 쉽습니다. 그림 1에서는 회사의 기존 전화 통신 시스템에 통합된 통합 메시징 솔루션의 예를 보여 줍니다. 지금부터는 이와 같은 방법으로 통합 메시징을 배포할 때 접하게 되는 몇 가지 일반적인 개념 및 기술에 대해 좀 더 자세히 살펴보겠습니다.
그림 1 PBX 및 통합 메시징 솔루션
그림 1 PBX 및 통합 메시징 솔루션
PBX(Private Branch Exchange)는 조직 내에서 사용되는 개인 전화 네트워크입니다. 이 시스템에서 각 사용자는 PBX에 연결된 전화를 사용하며 이 전화를 통해 대개 4자리나 5자리의 내선 번호를 사용하여 내부의 다른 사용자에게 전화를 걸거나 외부로 전화를 겁니다.
여러 위치에서 PBX를 사용하는 조직에서는 특정 PBX 공급업체의 네트워킹 기술을 통해 시스템을 서로 연결하는 경우도 있습니다. 이를 통해 네트워크로 연결된 PBX의 모든 사용자는 내선 번호만 눌러 서로 전화를 걸 수 있습니다.
통합 메시징에는 Exchange 메시징과 실제 전화 통신 시스템이라는 서로 다른 두 시스템을 통합하는 작업이 포함됩니다. 통합 메시징 서버와 전화 통신 아키텍처 간의 통신은 SIP(Session Initiation Protocol)를 사용하여 수행됩니다. PBX 기술에 따라서는 SIP를 통해 통합 메시징 서버와 직접 통신할 수 있지만 SIP 게이트웨이가 필요한 경우도 있습니다. 그림 1에서는 PBX가 T1 회선을 통해 SIP 게이트웨이에 연결되어 있습니다. 통합 메시징으로 호출이 전달되면 PBX가 발신자 전화 번호, 수신자 전화 번호, 이유 코드 등의 정보를 SIP 게이트웨이로 보내서 누구에게 걸려 온 호출인지를 통합 메시징 서버에서 알 수 있도록 합니다.
일부 PBX는 IP 네트워크를 통해 네트워크로 연결할 수 있습니다. 전화 통신 네트워킹에서는 IP 네트워크를 통해 중앙 집중화된 음성 메일 솔루션으로 호출을 리디렉션할 수 있는 기능을 제공합니다. 예를 들어 그림 2에서 취리히는 네트워크를 통해 다시 런던으로 연결됩니다.
그림 2 더 복잡한 통합 메시징 배포
그림 2 더 복잡한 통합 메시징 배포

호출 흐름
통합 메시징 리소스
  • 통합 메시징 전문 업체 카탈로그
  • Exchange 통합 메시징 TechCenter
  • 지원되는 SIP 게이트웨이
  • 전화 통신 관련 정보
  • PBX 구성 정보

외부 호출자로부터 통합 메시징 구독자 전화로 호출이 왔다고 가정해 보겠습니다. 이 경우 통합 메시징 구독자가 사무실에 없으므로 호출을 받을 수 없습니다. 그림 1을 보면 이 메시지의 경로를 추적할 수 있습니다.
PBX는 호출을 SIP 게이트웨이로 보냅니다. 그러면 SIP 게이트웨이가 SIP over TCP를 통해 통합 메시징 서버와 호출을 협상합니다. 통합 메시징 서버는 수신자가 누구인지 알려 주는 통합 데이터를 SIP 게이트웨이로부터 받습니다. 그러면 통합 메시징 서버가 구독자의 인사말을 재생하고 외부 호출자가 메시지를 녹음할 수 있도록 합니다. 그런 다음 녹음된 메시지는 통합 메시징 구독자의 Exchange 사서함으로 배달됩니다.
이 호출 흐름은 실제 흐름을 다소 간단하게 설명한 것입니다. 메시지가 녹음될 때 통합 메시징 서버는 SMTP를 통해 메시지를 허브 전송 서버로 전달하여 메시지가 사서함 서버로 배달될 수 있도록 한다는 것을 이해하는 것이 중요합니다.
이제 통합 메시징 구독자가 전화(Outlook® Voice Access를 사용하는 경우)나 컴퓨터(Outlook 2007 또는 Outlook Web Access를 사용하는 경우)를 통해 자신의 Exchange 사서함에 액세스합니다. Outlook 2007이나 Outlook Web Access를 사용하는 경우에도 '전화에서 재생'이라는 기능을 통해 전화로 메시지에 액세스할 수 있습니다. 이 기능을 사용하면 컴퓨터를 통해 메시지에 액세스하는 대신 지정된 전화에서 벨이 울리도록 설정하여 선택한 메시지를 통합 메시징에서 재생하도록 할 수 있습니다. 이 방법을 사용하는 경우 통합 메시징 서버가 클라이언트 액세스 서버 및 사서함 서버 모두와 상호 작용합니다. 로컬 클라이언트 액세스 서버가 없는 원격 사무실에 통합 메시징 서버를 배치하는 경우 통합 메시징 서버가 클라이언트 액세스 서버에 연결하기 위해 WAN을 경유해야 하는데, 이로 인해 성능이 저하될 수 있다는 점을 반드시 기억하고 있어야 합니다.

시스템 설계
Exchange 아키텍처 설계는 크게 중앙 집중화된 설계와 분산된 설계의 두 가지 방식으로 나뉩니다. 일반적으로 통합 메시징 아키텍처는 Exchange 아키텍처를 따릅니다. 즉, 사서함 서버를 배포한 곳에는 통합 메시징 서버도 배포합니다. 물론, 어느 규칙이라도 예외는 있습니다.
통합 메시징 아키텍처를 설계할 때는 다음과 같은 다섯 가지 기본 사항을 고려해야 합니다.
  • 서버 배치
  • 통합 메시징 서버의 수
  • SIP 게이트웨이
  • 사서함 저장소
  • 통합 메시징 사이트 구성
비즈니스 연속성도 간과해서는 안 됩니다. 일반적으로 Exchange와 관련된 재해 복구 계획을 사용하여 통합 메시징 관련 요소를 확인할 수 있습니다.
샘플 배포 시나리오는 통합 메시징 서버 역할을 이해하는 데 도움이 됩니다. 그림 2에서는 규모가 큰 조직에 배포된 Exchange Server 2007 및 통합 메시징을 보여 줍니다.
다소 복잡한 이 설계에서 주 데이터 센터는 시애틀과 런던입니다. 이 두 위치에서는 사서함 서버와 허브 전송 서버가 로컬에 있으므로 통합 메시징 서버가 해당 사용자 커뮤니티를 담당합니다. 두 위치 모두에는 로컬 통합 메시징 서버로 들어오는 모든 호출에 대한 응답을 담당하는 IP PBX가 있습니다.
중간 규모 사이트는 뉴욕과 글래스고에 있습니다. 이 두 위치에서는 사서함 서버와 허브 전송 서버가 로컬에 있으므로 통합 메시징 서버가 해당 사용자 커뮤니티를 담당합니다. 주 데이터 센터와 마찬가지로 두 사이트 모두에는 로컬 통합 메시징 서버로 들어오는 모든 호출에 대한 응답을 담당하는 IP PBX가 있습니다.
소규모 사이트에는 로컬 사서함 서버나 허브 전송 서버가 없지만 주 데이터 센터를 통해 통합 메시징 기능이 제공됩니다. 오스틴에는 로컬 SIP 게이트웨이에 대해 아날로그 연결을 사용하는 NEC PBX가 있습니다. 로컬 최종 사용자에게 걸려 온 호출은 SIP 게이트웨이로 전달됩니다. 그러면 SIP 게이트웨이가 시애틀의 통합 메시징 서버와 협상하여 통합 메시징을 통해 호출에 대한 응답을 제공합니다.
취리히에는 IP 네트워크를 통해 런던의 Avaya Communication Manager에 네트워크로 연결된 Avaya Communication Manager가 있습니다. 로컬 사용자에게 걸려 온 호출은 Avaya Communication Manager 네트워크를 통해 전달됩니다. 그러면 Avaya Communication Manager가 런던의 통합 메시징 서버와 협상하여 통합 메시징을 통해 호출에 대한 응답을 제공합니다.
이 예에서 시애틀 사이트에는 Exchange 사서함 서버와 통합 메시징 서버가 물리적으로 동일한 위치에 있습니다. 단일 사이트 아키텍처에서는 사서함, 통합 메시징, 클라이언트 액세스 등의 모든 서버와 PBX 장비가 동일한 사이트 내에 배치됩니다. 여러 사이트가 있는 회사의 경우에는 설계가 복잡해집니다. 이러한 복잡함으로 인해 어려움을 느낄 수도 있지만 통합 메시징의 몇 가지 기본 원칙을 제대로 이해한다면 쉽게 관리할 수 있습니다.
그림 2에서 볼 수 있듯이 한 사이트에 사서함 서버가 있으면 통합 메시징 서버도 동일한 사이트에 배치하는 것이 좋습니다. 시애틀, 런던, 뉴욕, 글래스고에는 모두 이 설계가 적용됩니다. 오스틴과 취리히에는 로컬 사서함 서버가 없지만 IP 네트워크를 통해 이 곳에도 통합 메시징 서비스를 제공할 수 있습니다. 오스틴에는 로컬 아날로그 PBX가 있습니다. 이 경우 시애틀의 통합 메시징 서버에 대한 IP 네트워크 연결을 제공하는 데 SIP 게이트웨이를 사용해야 합니다. 취리히에는 로컬 IP PBX가 있고 이 IP PBX는 네트워크를 통해 다시 런던의 PBX에 연결됩니다. 따라서 취리히의 사용자에게 온 호출은 전화 통신 네트워크를 경유하여 다시 런던의 PBX와 통합 메시징 서버로 전송됩니다.
취리히의 구독자에게 온 호출은 네트워크를 경유하고 런던의 중앙 집중화된 통합 메시징 시스템에서 처리되므로 네트워크 연결이 끊기면 연결이 복구될 때까지 취리히의 모든 구독자에게 온 호출은 응답되지 않습니다. 네트워크 연결이 끊긴 경우에도 로컬에서 서비스가 지속적으로 제공되어야 하는 경우에는 취리히에 통합 메시징 서버를 배치할 수 있습니다. 그러면 네트워크 연결이 끊기더라도 통합 메시징 서버가 계속해서 호출에 응답하고 네트워크가 복구되면 이를 전달할 수 있습니다.
서버 배치는 사용자 환경에 맞게 아키텍처를 설계할 때 고려해야 할 가장 중요한 요소입니다. 그림 3의 순서도를 보면 적절한 서버 배치를 결정하는 데 도움이 됩니다.
그림 3 서버 배치 결정
그림 3 서버 배치 결정

필요한 서버 수 예측
그 다음으로 고려해야 할 사항은 사용자 커뮤니티를 지원하는 데 필요한 통합 메시징 서버의 수입니다. 필요한 서버의 수는 실제로 몇 가지 사이트별 요소에 따라 다릅니다.
통합 메시징의 확장성은 서버에서 지원되는 동시 호출의 수(전화 통신의 경우 호출되는 포트 수)를 기준으로 결정됩니다. 시스템으로 들어오는 각 호출에 응답하려면 통합 메시징 서버에 전용 네트워크, CPU, 메모리 및 디스크 리소스를 할당해야 합니다. 리소스를 추가하면 통합 메시징 서버가 더 많은 동시 호출을 지원할 수 있습니다. 이러한 리소스는 늘 그렇듯 제한되기 마련이므로 통합 메시징 서버는 리소스에 과부하가 발생하지 않는 범위 내에서 가능한 수의 동시 호출만 처리할 수 있습니다.
Erlang의 트래픽 분석 계산법을 사용하면 구독자 수를 지원하는 데 필요한 포트 수를 결정할 수 있습니다. 이 계산법에 대해서는 여기에서 자세히 설명하지 않습니다. 전화 통신 관리자에게 기존 음성 메일 시스템에서 사용하는 음성 메일 포트 수를 문의하면 필요한 포트 수를 보다 쉽게 확인할 수 있습니다. 현장 경험에 비추어 볼 때 일반 음성 메일 시스템과 통합 메시징 시스템의 포트 요구 사항은 거의 비슷합니다.
일반적으로 서버당 구현하는 포트 수가 60개를 넘지 않도록 하는 것이 좋습니다. 이 수는 소프트웨어나 하드웨어의 제한 사항과는 아무 관계가 없으며 포트가 60개인 단일 서버에서 대략 5,000명의 사용자를 지원할 수 있다는 사실에 근거를 두고 산출한 것입니다. 단일 서버가 중단되면 규모가 매우 큰 전체 구독자 기반 중에서 해당 서버만 중단될 뿐입니다.
통합 메시징 서버를 구현할 때 N+1 중복 설계를 아키텍처에 포함할 수도 있습니다. 그림 4에서는 완전히 중복되는 서버 및 SIP 게이트웨이 설계를 보여 줍니다. 이 설계에 따르면 통합 메시징 서버 1이 중단되는 경우 SIP 게이트웨이 1이 자동으로 통합 메시징 서버 2와 호출을 협상합니다. SIP 게이트웨이 간에 호출 부하가 고르게 분산되도록 PBX를 프로그래밍할 수도 있습니다. 예를 들어 시스템으로 들어오는 첫 번째 호출은 SIP 게이트웨이 1로 라우팅하고 두 번째 호출은 SIP 게이트웨이 2로 라우팅할 수 있습니다. 각 게이트웨이가 교대로 호출을 수신하도록 함으로써 통합 메시징 서버 간에 호출을 고르게 분산하고 부하를 공유할 수 있습니다.
그림 4 중복성 제공을 위한 서버 간의 호출 분산
그림 4 중복성 제공을 위한 서버 간의 호출 분산
현재 Exchange Server 2007 통합 메시징 솔루션에서는 AudioCodes와 Dialogic의 두 가지 SIP 게이트웨이 공급자가 지원됩니다. 설계에 SIP 게이트웨이를 포함해야 하는 경우 설계에 필요한 세션(포트) 수를 지원하는 SIP 게이트웨이를 구입해야 합니다. 예를 들어 32개의 포트가 필요하면 적어도 32개 이상의 세션을 지원하는 게이트웨이를 사용해야 합니다.
사용 중인 PBX가 통합 메시징과 함께 작동하는지 여부나 어떤 게이트웨이를 사용해야 할지 잘 모르는 경우 "통합 메시징 리소스" 추가 기사를 참조하십시오. 추가 기사에 나열된 링크를 통해 Microsoft에서 제공하는 구체적인 지침 및 조직의 특정 요구 사항을 평가할 수 있도록 도움을 주는 통합 메시징 전문 업체 카탈로그를 볼 수 있습니다. 필자의 경험에 비추어 보면 SIP 게이트웨이 및 Exchange 통합 메시징과 함께 사용할 수 없는 PBX는 그다지 많지 않으며 일부 PBX의 경우 기본적으로 SIP over TCP를 사용하여 통합 메시징 서버와 통신할 수 있습니다.
Exchange 통합 메시징은 음성 메일 메시지 저장을 위해 G.711 PCM Linear, GSM 06.10 및 WMA(Windows Media® 오디오)의 세 가지 오디오 코덱을 지원합니다. PCM Linear WAV 파일은 오디오에 초당 약 16KB를 사용합니다. WMA는 통합 메시징의 기본 오디오 코덱으로, 초당 1.1kb(킬로비트)로 오디오를 압축하며 헤더 크기가 7KB입니다. GSM 06.10은 초당 1.6kb로 오디오를 압축하지만 WMA 인코딩보다 헤더가 작습니다.
WMA와 GSM 06.10 인코딩의 경우 음성 메시지의 음성 품질이 양호합니다. WMA나 GSM 코덱을 사용해 본 현장 경험에 비추어 보면 조직에서 음성 메일을 얼마나 많이 사용하는지 여부에 따라 사서함 저장소 크기가 10%-20% 정도 늘어날 수 있습니다.
사용자 환경에서 사용할 오디오 코덱을 결정할 때는 최종 사용자가 사용하는 모바일 장치 및 기타 운영 체제를 염두에 두어야 합니다. 오디오 코덱에 대한 질문은 대개 사용자가 자신의 Windows Mobile® 장치에서 음성 메일을 수신할 수 있는지에 관한 것입니다. 다른 운영 체제를 사용하는 경우도 고려의 대상입니다. 조직에서 WMA 파일을 재생할 수 없는 Linux 시스템을 대규모로 배포했을 수 있습니다. 어떤 경우에 해당하든 이러한 요소가 있으면 사용자 교육 시 고려해야 할 지원 센터 리소스 요구 사항이 늘어납니다.

구성 및 테스트
통합 메시징 아키텍처가 중앙 집중화되어 있는지 또는 분산되어 있는지 여부에 관계없이 조직에 통합 메시징을 배포하기 전에 먼저 수많은 음성 메일 요구 사항을 검토해야 합니다. "통합 메시징 검사 목록" 추가 기사에는 프로젝트 팀에서 논의해야 할 자세한 항목이 나열되어 있습니다. 통합 메시징을 구현하려는 각 사이트에서 모든 항목에 대한 정보를 수집해야 합니다. IT 팀과 전화 통신 팀은 이러한 항목을 고려할 때 상호 협력해야 합니다.
시스템을 설계하고 구성 작업을 마친 후에는 테스트 시스템을 가동하여 설계가 적절한지 검사해야 합니다. 여러 사이트를 대상으로 한 설계의 경우 적어도 둘 이상의 서로 다른 사이트를 테스트하여 POC(개념 증명)를 보여 주고 설계가 올바르게 작동하는지 검사하는 것이 좋습니다.
구성 요구 사항을 바탕으로 기능 테스트 계획을 수립한 다음 이를 수행해야 합니다. 기능 테스트 계획에는 구독자 액세스 방법(전화, Outlook 2007 및 Outlook Web Access), 관리 방법, 하드웨어 및 네트워크 중단이 포함되어야 합니다.
테스트가 완료된 후 모든 사용자들이 통합 메시징에 기존 음성 메일 시스템의 기능이 완벽하게 복제되었다는 데 동의하거나 복제할 수 없는 구성 또는 기능을 지원하기 위해 대체 솔루션을 설계해야 한다는 것에 동의한 경우에는 시스템을 테스트하기 위한 파일럿 사용자 그룹을 선정해야 합니다. 파일럿 그룹을 활용하면 사용자 환경에서 구독자를 기존 음성 메일 시스템에서 통합 메시징으로 이동(전화 통신 용어로는 전환)하는 데 필요한 단계를 파악할 수 있습니다. 일반적으로 구독자를 전환하는 데 필요한 단계는 다음과 같습니다.
  1. 기존 음성 메일 시스템에서 구독자를 비활성화합니다.
  2. Exchange 관리 콘솔을 통해 Active Directory의 구독자가 통합 메시징을 사용하도록 설정합니다.
  3. 전화 연결 경로를 통합 메시징 파일럿 번호로 변경합니다.
기존 사서함으로 메시지가 전송되지 않도록 기존 음성 메일 시스템에서 구독자를 반드시 비활성화해야 합니다.
파일럿 단계에서는 구독자가 시스템 기능과 관련하여 제기한 질문을 기록해야 합니다. 이러한 세부 사항을 문서화하면 교육 단계에서 일반적인 문제를 해결할 수 있습니다.
성공적인 전환을 위해서는 교육이 반드시 필요합니다. 사용자는 특정한 사용자 인터페이스를 사용하여 전화를 통해 음성 메일에 액세스하는 것에 익숙해져 있습니다. 예를 들어 일부 음성 메일 시스템의 경우 메시지를 청취하려면 5번을 눌러야 합니다. Exchange 통합 메시징에서는 1번을 누르거나 "음성 메일(Voicemail)"이라고 말해야 합니다. 또는 Outlook 2007이나 Outlook Web Access를 사용하여 음성 메시지를 재생해야 합니다. 통합 메시징 구독자 교육에는 전화 통신 사용자 인터페이스 탐색, Outlook Voice Access 탐색, Outlook/Outlook Web Access 탐색 과정을 포함해야 합니다.
Exchange 2007 통합 메시징을 사용하면 Outlook Voice Access에 기본으로 제공되는 음성 명령 실행 기능을 사용할 수 있습니다. 일부 사용자는 시스템의 새로운 기능에 상당한 흥미를 보이는데, 이 경우 기존 사용자 인터페이스에서 새로운 사용자 인터페이스로 전환하기가 훨씬 쉽습니다.
Exchange 통합 메시징에는 통합 메시징을 사용하도록 사용자를 설정하면 해당 사용자에게 사용자 지정 텍스트 전자 메일 메시지를 보내는 기능이 있습니다. 이러한 사용자 지정 메시지를 통해 FAQ(질문과 대답), 구독자 설명서, 지원 센터 전화 번호 등으로 연결되는 유용한 웹 링크를 제공할 수 있습니다. 음성 메일 시스템에 액세스하는 방법이나 구독자의 고유 암호와 같은 정보도 포함할 수 있습니다. 이 기능은 통합 메시징을 사용하도록 최종 사용자를 설정할 때 얻을 수 있는 가장 강력한 기능 중 하나입니다.

사용자 마이그레이션
통합 메시징 검사 목록
다음 단원에서는 통합 메시징 시스템의 몇 가지 기본 요소를 정의하고 Exchange Server 2007 통합 메시징의 배포 및 구성을 준비할 때 확인해야 할 몇 가지 질문을 보여 줍니다. 이러한 질문을 배포 계획을 수립하기 위한 검사 목록으로 사용할 수 있습니다.
다이얼 플랜 통합 메시징 다이얼 플랜은 논리적으로 PBX 및 관련 내선 번호에 해당합니다. 다음과 같은 다이얼 플랜의 몇 가지 측면을 사전에 검토해야 합니다.
  • 내선 번호에는 몇 자리의 숫자를 사용합니까?
  • 통합 메시징 시스템의 파일럿 번호는 무엇입니까?
  • 사용자가 외부 회선에 전화를 걸려면 어떤 번호를 눌러야 합니까?
  • 메시지에는 어떤 오디오 코덱을 사용합니까?
  • 회사 교환원의 내선 번호는 무엇입니까?
헌트 그룹 및 파일럿 번호 헌트 그룹은 특정 순서로 호출을 수신하도록 구성된 일련의 내선 번호입니다. 파일럿 번호는 헌트 그룹에 액세스하기 위해 호출되는 기본 내선 번호입니다. 헌트 그룹 구성원 내선 번호의 수는 설계에 포함된 음성 메일 포트 수와 같아야 합니다.
사서함 정책 음성 메일 사서함 정책은 Exchange 사서함 정책과 거의 비슷합니다. 다음은 검토할 만한 몇 가지 정책입니다.
  • 음성 메일을 삭제하기 전에 며칠 동안 보관합니까?
  • 음성 메일 암호 재설정 간격은 어떻게 됩니까?
  • 음성 메일 백업 정책은 무엇입니까?
  • 최소 암호 길이 요구 사항은 무엇입니까?
  • 사서함을 잠그기 전까지 허용할 최대 로그온 시도 횟수는 얼마입니까?
AA(자동 전화 교환) 자동 전화 교환은 특정 구독자가 지정되지 않은 들어오는 호출에 응답합니다. 자동 전화 교환은 호출자에게 정보를 제공하고 호출자를 조직 내의 특정 위치로 리디렉션할 수 있습니다. Exchange 통합 메시징은 AA 탐색을 위한 DTMF 및 음성 기능을 제공합니다. 고려해야 할 사항은 다음과 같습니다.
  • 주간, 야간, 공휴일에 각기 다른 AA 메시지를 사용합니까? 이러한 메시지는 문서화하고 기록해야 합니다.
  • AA 메뉴에서 누구에게 전화를 걸 수 있습니까?
  • AA를 사용할 때 음성 탐색 기능을 사용할 수 있습니까?
  • AA를 사용하는 데 여러 언어가 필요합니까?
일반 또는 야간 사서함 일부 조직에서는 호출자가 일반 배달 메시지를 남길 수 있도록 일반 또는 야간 음성 메일 사서함을 사용합니다. 회사에 이러한 사서함이 있는 경우 Exchange 사서함을 만들고 통합 메시징을 사용하도록 설정해야 합니다.
MWI(메시지 대기 신호) 메시지 대기 신호란 사서함에 읽지 않은 음성 메시지가 있음을 알려 주는 전화기의 불빛을 말합니다. 전화기의 메시지 대기 신호 기능이 배포 요구 사항에 해당하는지 검토해야 합니다.
다중 내선 번호 지원 대부분의 조직에는 여러 개의 전화 번호를 사용하는 직원이 있습니다. 통합 메시징을 사용하도록 이러한 구독자를 설정할 때 해당 내선 번호를 모두 연결해야 합니다. 작업을 시작하기 전에 여러 개의 전화 번호를 사용하는 직원의 목록을 만들면 편리합니다.
IVR(대화식 음성 응답) 지원 기존의 일부 음성 메일 시스템에서는 통합 메시징으로 복제할 수 없는 IVR 응용 프로그램을 지원합니다. 대체하려는 시스템에 이러한 응용 프로그램이 연결되어 있는지 확인합니다. 이러한 응용 프로그램은 기존 시스템에 그대로 두거나 대체 IVR 응용 프로그램으로 바꿔야 할 수 있습니다.
음성 메일 네트워킹 음성 메일 네트워킹은 한 시스템에서 다른 시스템으로 메시지를 전송할 수 있는 기능을 제공합니다. 예를 들어 대규모 기업의 경우 CEO가 조직 전체에 음성 메시지를 보내거나 소방 훈련과 같은 일반 정보를 알려야 할 경우가 있습니다. 음성 메일 네트워크가 구축되어 있으면 직원이 어떤 음성 메일 시스템을 사용하든 CEO가 음성 메시지를 한 번 녹음한 후 이를 회사 내 모든 직원에게 보낼 수 있습니다. 현재 Exchange 통합 메시징에는 기존의 다른 음성 메일 시스템과 네트워크로 연결할 수 있는 기능이 없습니다.
팩스 지원 기존의 일부 음성 메일 플랫폼에서는 수신 팩스를 지원하므로 전화 번호 하나로 음성 메시지와 수신 팩스를 모두 받을 수 있습니다. Exchange Server 2007 통합 메시징에서는 수신 팩스를 지원하므로 기존 기능 대신 사용할 수 있습니다. 이 기능은 단방향이므로 송신 팩스 기능은 지원되지 않습니다. 송신 팩스 기능이 필요한 경우 이를 지원하는 타사 제품을 사용해야 합니다.

시스템을 완전한 프로덕션 환경으로 마이그레이션하는 방법에 대해서는 다양한 견해가 있습니다. 그 중에서 많이 사용되는 두 가지 방법은 점진적 마이그레이션과 일괄 전환(flash-cut)입니다. 어떤 방법을 선택하든 파일럿 그룹으로부터 수집하여 기록한 일반적인 질문을 바탕으로 지원 센터 직원들을 교육해야 합니다. 또한 통합 메시징을 사용하도록 사용자를 설정하는 방법, 사용자가 설정되었는지 확인하는 방법, 암호를 변경하는 방법 등도 교육해야 합니다.
이전의 음성 메일 시스템에서 통합 메시징으로 사용자를 마이그레이션하는 작업은 쉽지만 사전에 알고 있어야 할 한 가지 중요한 사항이 있습니다. 바로 음성 메일 네트워킹입니다. 전자 메일 시스템을 통해 다른 전자 메일 사용자와 시스템에 메시지를 보내고, 전달하고, 회신할 수 있는 것처럼 음성 메일을 통해서도 다른 음성 메일 사용자와 시스템에 메시지를 보내고, 전달하고, 회신할 수 있습니다.
현재 기존 음성 메일 시스템을 사용하고 있는 Alice와 Brian이 있다고 가정해 보십시오. Brian은 통합 메시징으로 마이그레이션되었고 기존 음성 메일 시스템을 사용하고 있는 Alice에게 메시지를 보내려고 합니다. 하지만 두 사용자가 서로 다른 시스템을 사용하고 있으므로 더 이상 서로에게 음성 메일을 보내거나 전달하거나 회신할 수 없습니다. 아쉽게도 음성 메일이 서로 고립된 것입니다.
기존의 음성 메일 시스템에서는 일종의 네트워킹 프로토콜 변환기를 사용하여 서로 다른 시스템을 네트워크로 연결함으로써 이 문제를 해결했습니다. 하지만 현재로서는 서로 다른 시스템을 네트워크를 통해 Exchange Server 2007 통합 메시징에 연결할 수 있도록 지원하는 네트워킹 프로토콜 변환기가 없습니다. 조직에 따라서는 이것이 큰 문제가 아닐 수도 있지만 소규모 그룹에서 사용자를 마이그레이션하는 경우에는 반드시 알고 있어야 할 사항입니다.
필자는 사이트 단위로 모든 사용자를 새 시스템으로 일괄 전환하는 방법을 선호합니다. 일괄 전환(flash-cut)이란 이전 시스템의 사용을 중단하고 새 시스템에서 새로 시작하는 것을 말합니다. 이 작업은 대개 주말에 이루어집니다. 사용자가 금요일에 퇴근한 후 월요일에 출근하면 새 음성 메일 시스템이 기다리고 있습니다. 일부 관리자는 소규모 기업 고객이나 원격 위치에서만 일괄 전환을 사용해야 한다고 말합니다. 그러나 필자는 사용자 수가 7,000명이 넘는 단일 위치에서 일괄 전환을 수행하는 데 참여한 적이 있었는데 당시 지원 센터에 도움을 요청한 직원은 전체의 1%도 되지 않았습니다. 프로젝트의 다른 모든 단계를 철저히 계획하여 올바르게 수행한다면 완전한 프로덕션 시스템으로의 전환이 원활하게 이루어질 것입니다.
하지만 여러 사이트를 완전한 프로덕션 환경으로 전환할 때는 먼저 소규모의 원격 사이트를 한 번에 하나씩 전환한 후에 가장 큰 규모의 사이트를 이동하는 것이 좋습니다. 소규모 사이트에서 얻은 경험을 검토하여 필요한 변경 사항을 프로젝트 계획에 반영합니다.
일반적으로 새로운 시스템을 사용하기 전에 모든 사용자 교육을 완료해야 하고 통합 메시징을 사용하도록 모든 사용자를 설정해야 합니다. 다음은 음성 메일 시스템의 일괄 전환을 준비하는 데 필요한 단계별 방법입니다.
가장 먼저 해야 할 작업은 통합 메시징 시스템이 완벽하게 설치, 구성 및 테스트되었는지 확인하는 것입니다.
그런 다음 소규모 그룹 단위로 교육을 실시합니다. 교육에 참석하는 사용자에게 각자의 사서함이 새 음성 메일 시스템에서 가동되기 전에 활성화될 것이라는 점을 설명합니다. 그런 다음 사서함에 로그인한 후 암호를 변경하고 인사말을 녹음하여 각자의 사서함을 초기화하도록 사용자들에게 알려 줍니다. 교육이 끝나면 즉시 통합 메시징을 사용하도록 사용자들을 설정하여 전환을 시작하기 전에 사용자들이 각자의 사서함을 초기화할 수 있도록 합니다.
마지막으로, 모든 교육이 끝나면 기존의 음성 메일 시스템에서 모든 사용자를 비활성화하고 사용자의 전화를 Exchange 통합 메시징으로 전달하는 작업을 수행하기에 적합한 주말을 선택합니다. 월요일 아침이 되면 조직의 모든 사용자를 위한 새 통합 메시징 시스템이 가동될 것입니다.

전환 시작
지원해야 할 대상이 단일 사이트인지 여러 사이트가 있는 대규모 조직인지 여부에 관계없이 이 문서에서 제공하는 정보는 분명히 도움이 될 것입니다. 여러 사이트가 있는 조직의 경우 설계가 복잡해질 수 있지만 사용자가 50명이든 5,000명이든 기본 요구 사항은 같습니다.
통합 메시징 솔루션을 배포할 때 IT 팀과 전화 통신 팀이 상호 협력해야 한다는 사실은 아무리 강조해도 지나치지 않습니다. 필자의 경험으로 미루어 보면 통합 메시징 프로젝트를 본 궤도에서 이탈하게 만들 수 있는 여러 가지 요인 중에서도 특히 IT 팀과 전화 통신 팀 간의 불협화음 및 솔루션에 대한 의견 불일치는 곧바로 실패로 이어집니다. 기술의 수렴은 그다지 어려운 것이 아닙니다. 하지만 팀의 협력을 도모하거나 성공적인 프로젝트 배포 계획을 수립하려면 IT와 전화 통신 모두에 대해 잘 알고 있는 조직 외부의 누군가로부터 도움이 필요할 수도 있습니다.

Jeff GoodwinVIA Group의 수석 기술자이자 Exchange 및 통합 메시징 설계 및 배포 분야의 전문가입니다. 문의 사항이 있으면 jgoodwin@theviagroup.com으로 연락하십시오.


 Security: 기본 컴퓨터 범죄 조사 가이드
Security Tom Cloward and Frank Simorjay

기본 컴퓨터 범죄 조사 가이드
한 눈에 보기:
  • Windows에 대한 기본적인 컴퓨터 조사 가이드
  • 맬웨어 제거 시작 키트
  • Windows PE로 조사 키트 만들기
  • 범죄 조사 분석을 위한 정보 보존

악의적인 사용자가 컴퓨터를 이용하여 불법 행위를 자행하는 방법은 시스템 해킹, 거래 비밀 정보 누출, 새 바이러스 배포, 피싱 메시지를 사용한 개인 정보 절취 등 셀 수 없이 많습니다. 게다가 새로운 악용 사례와 방법이 끊임없이
출현하고 있습니다. 그러나 컴퓨터를 활용하여 이러한 행위를 조사하는 방법에 대해서는 많이 알려진 바가 없습니다.
고도의 훈련을 받은 전문가를 동원하여 값비싼 도구와 복잡한 기술을 사용해야 하는 조사도 있지만 보다 쉽고 저렴한 방법을 통해 기본적인 조사와 분석을 수행할 수 있습니다. 이 기사에서는 관리자가 바로 활용할 수 있는 컴퓨터 범죄 조사 기술을 중점적으로 다룹니다.
여기서는 무료로 다운로드 가능한 두 개의 솔루션 액셀러레이터인 "Windows에 대한 기본적인 컴퓨터 조사 가이드"(go.microsoft.com/fwlink/?LinkId=80344)와 맬웨어 제거 시작 키트(go.microsoft.com/fwlink/?LinkId=93103)를 이용합니다. 이 기사에서는 두 가지 솔루션을 함께 사용하여 부팅 가능한 Windows® PE 환경을 구축하는 방법에 대해 설명합니다. 이를 통해 효과적인 조사를 수행하고 발견 내용을 보존하여 보고 및 분석할 수 있습니다. 암호화되었거나 RAID 볼륨의 일부인 하드 드라이브를 조사할 때는 여기에 설명된 방법을 사용할 수 없습니다. 또한 하드 드라이브가 손상된 경우에는 상태 복원을 위한 별도의 단계를 신속하게 수행해야 합니다.
이 솔루션에서는 Windows 기반 컴퓨터에서 증거를 수집할 수 있는 쉬운 방법을 자세히 설명하지만 이는 기본적이고 임시적인 방법입니다. 여기에 설명된 작업을 훨씬 효율적으로 실행할 수 있는 몇 가지 정교한 솔루션이 시판되고 있습니다.
또한 이 기사에서 소개하는 기술은 보증된 솔루션이 아니며 International Society of Forensic Computer Examiners의 인증을 받지 않았음을 유의하십시오. 조사를 시작하기 전에 하드 드라이브의 증거가 향후 법적 절차에 사용될 수 있는지 여부를 고려해야 합니다. 법적 절차에 사용될 가능성이 있는 경우 전문적으로 인증된 컴퓨터 조사자가 해당 조사에 참여해야 합니다. 모든 잠재적 법적 절차의 특성에 따라 조사를 직접 사법 기관에 전달해야 하는지 여부도 고려해야 합니다. "Windows에 대한 기본적인 컴퓨터 조사 가이드"에서 이 주제에 대한 자세한 내용을 볼 수 있습니다.

솔루션 액셀러레이터 정보
"Windows에 대한 기본적인 컴퓨터 조사 가이드"에서는 내부 컴퓨터 조사에 사용할 수 있는 프로세스와 도구에 대해 설명합니다. 이 가이드에서는 컴퓨터 조사 모델의 네 단계인 평가, 획득, 분석 및 보고에 대해 개괄적으로 설명합니다. 이 모델은 IT 전문가가 중요한 발견 내용을 보존하는 방식으로 조사를 수행하는 데 유용합니다.
또한 이 가이드에서는 사법 기관의 관여가 필요한 시점에 대해서도 다룹니다. 이에 대한 결정을 내릴 때는 법적 자문을 구해야 합니다. 컴퓨터 관련 범죄 관리, 적절한 사법 기관에 연락하는 방법, 조사 수행에 유용한 Windows Sysinternals 도구 및 기타 Windows 도구에 대한 정보를 얻을 수 있습니다.
이 기사에서 참조하는 또 다른 솔루션 액셀러레이터인 맬웨어 제거 시작 키트는 컴퓨터에서 맬웨어를 제거하기 위해 부팅 가능한 Windows PE CD-ROM을 만들고 사용하는 방법을 안내합니다. 이 가이드에는 위험 요소가 정리되어 있으며 이러한 위험 요소가 잠재적으로 조직에 미치는 영향을 줄일 수 있는 몇 가지 유용한 대책이 포함되어 있습니다. 또한 맬웨어 침투가 의심될 때 적용할 수 있는 사고 대응 계획 수립의 중요성도 강조하여 설명합니다. 맬웨어 제거 시작 키트에는 IT 전문가가 관련 맬웨어의 특성을 파악하고, 확산을 막고, 가능한 경우 이를 제거하고, 제거 여부를 확인하고, 필요한 추가 단계를 진행하는 데 유용한 네 가지 단계도 포함되어 있습니다.

Windows PE CD-ROM
이러한 유형의 조사를 수행하려면 Windows PE CD-ROM 및 외부 저장 장치(예: USB 플래시 드라이브)라는 두 가지 필수 구성 요소가 필요합니다.
TV에서 늘 보던 바와 같이 경찰관은 범죄 현장을 그대로 보존해야 합니다. 이와 마찬가지로, 조사할 하드 드라이브의 데이터도 그대로 보존해야 합니다. 맬웨어 제거 시작 키트 디스크와 달리, 우리가 제작하려는 부팅 가능한 Windows PE 디스크는 하드 드라이브 데이터를 전혀 변경하지 않는 방식으로 도구를 실행합니다.
Windows PE 디스크는 제한된 Windows 환경으로 시스템을 부팅합니다. 이 부팅 가능 CD를 만들 때 맬웨어 제거 시작 키트의 도구처럼 특별한 용도로 사전에 구성된 도구를 넣을 수 있습니다. 컴퓨터의 RAM 크기는 최소 512MB이어야 하며 이는 Windows PE 요구 사항입니다.
맬웨어 제거 시작 키트에 설명된 Windows PE CD-ROM을 만드는 과정은 꽤 간단합니다. 이 부팅 가능 디스크를 만들기 위해서는 먼저 Windows AIK(자동 설치 키트)와 Sysinternals Suite(microsoft.com/technet/sysinternals/utilities/sysinternalssuite.mspx에서 사용 가능)를 설치하고 맬웨어 제거 시작 키트의 2번 작업에 설명에 따라 도구 목록에 Sysinternals 도구를 배치한 다음 기타 맬웨어 검사 도구와 유틸리티를 설치해야 합니다. 디스크 제작에 대한 자세한 지침은 맬웨어 제거 시작 키트 문서에 설명된 단계를 참조하십시오.

외부 USB 드라이브
이 프로세스에서는 조사 대상 드라이브를 변경하지 않을 것이므로 생성되는 출력 파일을 저장할 수 있는 USB 드라이브 또는 다른 종류의 외부 하드 드라이브도 있어야 합니다. Windows PE에서는 USB 장치를 자동으로 탑재할 수 있으므로 USB 드라이브를 권장합니다. 외부 하드 드라이브를 사용하여 원래 하드 드라이브의 이미지를 저장할 수도 있습니다. 이러한 모든 요구 사항 및 옵션을 비롯하여 조사에 필요한 전체 디스크 공간을 고려하고 미리 계획을 세우는 것이 중요합니다.
깨끗한 키트로 조사를 시작하기를 원하므로 조사 파일을 저장하는 데 사용할 외부 디스크 드라이브에서 이전 데이터를 모두 완전히 제거해야 합니다. 이때 쓰기 가능한 전체 드라이브 표면을 덮어쓰는 디스크 지우기 유틸리티를 사용하면 데이터를 쉽게 제거할 수 있습니다. 그런 다음 외부 디스크를 포맷하고 조사 용도에 따라 레이블을 지정할 수 있습니다. 이 주의 사항을 준수하면 조사 도중 수집한 증거를 훼손할 수 있는 파일을 장치에서 제거할 수 있습니다.
또한 증거물 처리 과정 양식을 포함하여 조사 과정에서 컴퓨터를 다룬 사람에 대한 공식 문서가 작성될 수 있도록 해야 합니다. "Windows에 대한 기본적인 컴퓨터 조사 가이드"에서 간단한 증거물 처리 과정 양식을 제공합니다. 필요한 부팅 가능 Windows PE 디스크, 외부 저장 장치 및 증거물 처리 과정 양식을 비롯한 키트 구성을 마친 후에는 다음 단계를 진행할 수 있습니다.

조사 수행
이제 조사를 수행할 준비가 되었습니다. 먼저 컴퓨터의 부트 순서에서 CD-ROM 드라이브를 기본 부트 장치로 지정한 다음 Windows PE 디스크를 사용하여 조사 시스템을 부팅합니다. 메시지가 나타나면 아무 키나 눌러 CD-ROM 부팅을 완료합니다. 그러면 디스크에 설치된 도구에 액세스할 수 있습니다.
여기서는 샘플 컴퓨터에서 키트를 사용하여 컴퓨터(이하 Testbox1)로부터 정보를 수집하는 방법에 대해 설명합니다. Testbox1에 할당된 CD 드라이브는 X:\이며 맬웨어 제거 시작 키트의 도구에 제공되는 기본 위치는 X:\tools입니다. 키트의 도구에 액세스하려면 cd \tools를 입력하면 됩니다.
몇 가지 도구를 사용하여 컴퓨터에 탑재된 대상 드라이브를 식별할 수 있습니다. Sysinternals 도구 디렉터리에 있는 Bginfo.exe를 사용하여 이 정보를 확인할 수 있으며 해당 정보를 바탕 화면의 배경 창에 두고 쉽게 참조할 수 있습니다. Drive Manager 역시 대상 하드 디스크 드라이브 및 외부 USB 장치를 비롯한 컴퓨터의 모든 장치를 식별할 수 있습니다. 그림 1에서 Testbox1의 디스크 정보를 볼 수 있습니다. 부트 드라이브는 X:\, 대상 하드 드라이브는 C:\, 외부 USB 드라이브는 F:\입니다.
그림 1 Drive Manager로 디스크 정보 보기
그림 1 Drive Manager로 디스크 정보 보기

맬웨어 검사
바이러스나 기타 악성 코드가 조사에 영향을 미치지 않도록 하려면 조사를 시작하기 전에 맬웨어 방지 도구를 실행해야 합니다. 필요한 경우 맬웨어 방지 도구에서 생성되는 보고서를 증거로 사용할 수 있습니다. 컴퓨터의 맬웨어를 검사하지 않으면 완벽함 및 정확성 측면에서 조사자의 신뢰도뿐만 아니라 조사 자체가 위태로울 수 있습니다. 제공된 맬웨어 방지 도구는 읽기 전용 또는 보고 모드로 실행하는 것이 좋습니다.
맬웨어 제거 시작 키트에서는 악성 소프트웨어 제거 도구 및 McAfee AVERT Stinger를 포함한 몇 가지 권장 도구를 소개합니다. 악성 소프트웨어 제거 도구를 실행할 때는 맬웨어를 보고만 하고 제거하지 않도록 지시하는 명령줄 옵션 /N을 반드시 포함해야 합니다.
x:\tools\windows-KB890830-v1.29.exe /N
결과 보고서 파일은 %windir%\debug\mrt.log에 생성됩니다.
마찬가지로 McAfee AVERT Stinger를 실행할 때는 컴퓨터를 검사만 하고 하드 드라이브를 변경하지 않도록 그림 2에서처럼 기본 설정을 Report only(보고 전용)로 변경합니다. 또한 검사를 완료하면 도구에서 보고서를 저장하도록 합니다.
그림 2 McAfee AVERT Stinger에서 Report only(보고 전용) 모드 사용
그림 2 McAfee AVERT Stinger에서 Report only(보고 전용) 모드 사용

중요 파일 저장
전체 디스크가 백업되지 않은 경우 조사를 시작하기 전에 중요한 사용자 파일만이라도 백업을 해두어야 합니다. 필요한 경우 향후 검토 작업에 구성 정보를 활용할 수 있습니다. 컴퓨터가 사용된 방식 및 시스템에 설치된 소프트웨어에 대한 모든 관련 정보가 들어 있는 레지스트리 파일과 설정을 수집합니다.
Testbox1에 대한 레지스트리 하이브를 저장하려면 먼저 이동식 드라이브 F:\에 폴더를 만든 다음 아래의 명령을 사용하여 조사가 시작된 날짜와 시간을 기록합니다.
f: Mkdir f:\evidence_files Date /t >> f:\evidence_files\Evidence_start.txt Time /t >> f:\evidence_files\Evidence_start.txt
이제 xcopy 명령으로 전체 구성 디렉터리와 해당 콘텐츠를 복사하여 레지스트리 하이브를 저장합니다. 여러분이 관심을 가질 만한 레지스트리 파일은 %windows%\system32\config에 있습니다. 이 예제에서는 다음을 실행합니다.
xcopy c:\windows\system32\config\*.* f:\registrybkup /s /e /k /v
이 명령을 실행하면 config 폴더의 모든 구성 정보가 복사됩니다. Textbox1의 config 폴더에는 약 95MB의 정보가 들어 있습니다.
다음으로는 하드 디스크의 모든 위치에 존재할 수 있는 사용자 데이터에 대해 살펴보겠습니다. 이 샘플에서는 c:\HR이라는 디렉터리의 데이터만 복사합니다. 데이터를 완전히 수집하기 위해 아래와 같은 xcopy 명령을 사용하여 디렉터리 및 해당 하위 디렉터리의 모든 데이터를 복사합니다.
Mkdir f:\evidence_files\HR_Evidence Mkdir f:\evidence_files\documents_and_settings Mkdir f:\evidence_files\users xcopy c:\HR\*.* f:\evidence_files\HR_Evidence /s /e /k /v
이제 개인 폴더 정보로 넘어갑니다. 이번에도 역시 이 디렉터리 및 해당 하위 디렉터리의 모든 데이터를 복사하고자 합니다. 이렇게 하려면 다음 명령을 사용합니다.
Xcopy c:\documents and settings\*.* f:\evidence_files\documents_and_settings /s /e /k /v

Xcopy c:\users\*.* f:\evidence_files\users /s /e /k /v
이 샘플을 실행하면 약 500MB의 데이터가 수집되고, 필요한 경우 이를 분석할 수 있습니다. 여기서 알 수 있듯이 수집하는 데이터 양은 매우 방대해질 수 있으며 오디오 파일, 비디오 및 사진이 있을 때는 그 양이 더욱 많아집니다. 그러나 조사에는 물리적으로 수집한 증거뿐 아니라 이 정보가 수집 프로세스 도중 변경되지 않았다는 확증이 필요할 수도 있으므로 가능한 한 많은 양의 원본 데이터를 보존하는 것이 중요합니다. 이론적으로는 조사에 사용할 전체 디스크 이미지를 만들어야 하지만 이는 크기 제한 때문에 실행에 어려움이 따릅니다. 바로 이러한 이유로 인해 조사에 필요한 저장 공간의 크기를 미리 고려해 두는 것이 매우 중요합니다.

추가 정보 수집
시스템 파일 역시 증거 수집에 유용한 자산으로 활용할 수 있지만 이러한 파일은 항상 같은 위치에 있는 것이 아니므로 해당 데이터를 수집하려면 대상 컴퓨터에 대한 탐색 작업이 어느 정도 필요할 수 있습니다. 그렇더라도 특정 유형의 파일을 통해 유용한 정보를 참조할 수 있으므로 살펴볼 가치가 있습니다. 예를 들어 스왑 파일에는 메모리에서 액세스한 파일에 대한 정보가 들어 있습니다. 또한 스왑 파일을 통해 자세한 사용 작업도 확인할 수 있습니다. 마찬가지로 웹 브라우저 데이터와 쿠키는 탐색 동작과 패턴에 대한 정보를 제공합니다.
특히 사용자가 데이터를 기본 위치가 아닌 곳에 저장하도록 구성한 경우 이러한 데이터를 찾으려면 다소 세밀한 조사가 필요합니다. 이러한 중요한 파일을 찾도록 도와주는 몇 가지 Sysinternals 도구가 있습니다. 그림 3에는 다섯 가지 유용한 응용 프로그램 및 이를 조사에 활용할 수 있는 방법이 설명되어 있습니다.
Figure 3 파일 및 데이터 검색 도구 (Close Figure 3)

응용 프로그램 | 설명
AccessChk | 지정한 사용자 또는 그룹이 액세스할 수 있는 파일, 레지스트리 키 및 Windows 서비스를 표시합니다.
AccessEnum | 컴퓨터의 디렉터리, 파일 및 레지스트리 키에 액세스한 사용자를 표시합니다. 이를 통해 사용 권한이 적절하게 적용되지 않은 부분을 찾을 수 있습니다.
Du | 디렉터리별로 디스크 사용량을 표시합니다.
PsInfo | 컴퓨터에 대한 정보를 표시합니다.
Strings | 이진 이미지에서 ANSI 및 UNICODE 문자열을 검색합니다.

Tom ClowardCCE, CISSP 자격증 보유자로, IT 전문가를 위한 보안 및 규정 준수 솔루션 액셀러레이터 제공 업무에 주력하고 있는 Microsoft 프로그램 관리자입니다. 소프트웨어 및 IT 업계에서 15년 이상 근무해 왔으며 IT 보안, 범죄 조사 및 규정 준수 분야에 많은 관심을 갖고 있습니다.
Frank SimorjayCISSP 및 CET 자격증 보유자로 기술 프로그램 관리자 겸 Microsoft Solution Accelerator 보안 및 규정 준수 그룹의 보안 관련 전문가입니다. Microsoft 고객을 위한 보안 솔루션 설계 업무를 맡고 있으며 최근에는 Microsoft TechNet에 맬웨어 제거 시작 키트에 대한 기사를 게시했습니다.


 Networking: Microsoft Security Intelligence Report(보안 정보 보고서)
Networking Tim Rains

Microsoft Security Intelligence Report(보안 정보 보고서)
한 눈에 보기:
  • 소프트웨어 취약점 노출, 악용 및 맬웨어의 경향
  • 다양한 Windows 버전에 대한 위협의 영향
  • 전 세계에서 감염률이 가장 높은 지역 및 가장 낮은 지역

인터넷으로 연결된 수많은 컴퓨터 및 전 세계에서 사용량이 가장 많은 일부 온라인 서비스에서 수집한 데이터를 통해 Microsoft는 오늘날의 인터넷 사용자가 직면해 있는 보안 위협에 대해 독창적인 시각을 보유할 수 있게 되었습니다.
Microsoft는 SIR(보안 정보 보고서)을 통해 이러한 데이터를 연 2회에 걸쳐 공유하고 있습니다. MMPC(Microsoft® Malware Protection Center), MSRC(Microsoft Security Response Center), TwC(Trustworthy Computing) 그룹 및 수많은 다른 제품 그룹에서 이 보고서에 들어갈 의견을 제공합니다. SIR을 참조하면 소프트웨어 취약점 노출, 악성 소프트웨어, 스파이웨어나 애드웨어 같은 원치 않는 소프트웨어의 최신 경향을 심층적으로 살펴볼 수 있습니다. 또한 이 보고서에서는 위협 환경 내에서 다양한 버전의 Windows 운영 체제가 반응하는 양상 및 전 세계에서 맬웨어 또는 기타 침입형 소프트웨어의 감염률이 가장 높은 지역을 자세히 보여 줍니다. 최신 버전의 보고서에서는 2007년 상반기에 관찰된 경향을 중점적으로 다루고 있으며 소프트웨어 취약점 악용에 대한 단원이 새로 추가되었습니다. SIR은 인터넷 관련 위협에 대한 정보를 제공하는 것이 그 목적입니다. 컴퓨터 보안 업무를 담당하고 있거나 이 분야에 관심이 있는 사용자의 경우 SIR을 참조하면 많은 도움을 받을 수 있습니다.
최신 버전의 SIR을 보면, 모든 공급업체에서 제공하는 소프트웨어에서 점점 많은 취약점이 발견되고 있다는 사실을 알 수 있습니다. 실제로 2007년 상반기에만 3,400가지나 되는 소프트웨어 취약점이 새롭게 노출되었습니다. 하지만 이 엄청난 수치에도 불구하고 운영 체제에서 노출되는 취약점의 비율은 전반적으로 감소하고 있습니다.
여기에는 어떤 의미가 있을까요? 운영 체제의 보안은 그동안 꾸준히 개선되어 온 사항이므로 보안 조사 팀에서 응용 프로그램의 보안 문제 발견에 더 주력한 것일 수 있습니다. 또한 새 응용 프로그램의 출현 속도는 새 운영 체제의 출현 속도를 앞지르고 있으므로, 이와 같은 최근의 취약점 노출 문제는 응용 프로그램의 확산으로 인한 것일 수도 있습니다.
2006년에는 Microsoft 제품의 알려진 취약점 중 공개적으로 이용 가능한 공격 코드가 포함된 취약점은 29.3%에 달하였지만, 2007년 8월 1일 현재 이러한 공격 코드가 포함된 취약점은 20.9%뿐입니다. 취약점의 수는 계속 증가하고 있지만 공격 코드의 비율은 그대로이거나 오히려 조금 감소했습니다. 새로운 제품에서는 공격 코드를 쉽게 찾아볼 수 없습니다. Microsoft는 제품별 비교 작업을 수행한 결과, 새로운 버전의 제품일수록 기존 버전에 비해 위험에 덜 노출되어 있다는 사실을 알게 되었습니다. 평균적으로 취약점 공격 가능성은 제품 사용 주기에 따라 낮아지는데, 이는 곧 대부분의 제품의 경우 최신 버전일수록 공격 가능성이 낮아진다는 의미가 됩니다. 이러한 현상은 Windows 및 Microsoft Office System 제품에서 가장 두드러지게 나타납니다. 두 제품군 모두 최신 버전(Windows Server® 2003, Windows Vista®, Office 2003, 2007 Office system)일수록 전체 제품 사용 주기를 통틀어 취약점 수의 현저한 감소세를 보였습니다.
SIR은 악성 소프트웨어(맬웨어)의 추세를 파악하는 데 매우 유용합니다. 이러한 추세는 현재 사용자를 공격하는 데 이용되는 방법을 알 수 있는 지표입니다. 또한 Microsoft EHS(Exchange Hosted Services), Windows LiveWindows Live® OneCare와 Windows Live OneCare 보안 검사, Windows MSRT(악성 소프트웨어 제거 도구), Windows Defender를 비롯한 몇몇 주요 소스에서 제공하는 데이터를 참조하면 현재의 위협 환경을 보다 정확하게 파악할 수 있습니다.
사회 공학(Social Engineering) 기술이 맬웨어의 배포에 점점 더 많은 비중을 차지하고 있습니다. 사회 공학 기술을 이용한 공격은 대개 사용자가 보안 수단의 효용성을 떨어뜨리는 작업을 수행하도록 유도하여 그 효력을 발휘합니다. EHS의 데이터를 보면 2006년 상반기 동안 고전적인 전자 메일에서 기인한 가장 큰 단독 위협 요소는 고전적인 전자 메일 웜이었으며, 이는 전자 메일에서 발견된 맬웨어의 95%를 차지했습니다. 2006년 하반기가 시작될 무렵 이 수치는 49%로 떨어졌으며 2007년 상반기 내내 이 수준으로 유지되었습니다(그림 1 참조). 2006년 하반기에는 피싱 사기 및 악성 IFrame 공격이 전자 메일 맬웨어의 27%를 차지했으며 2007년 상반기에는 이 수치가 37%로 증가했습니다. 전자 메일을 통해 전달되는 Trojan Downloader는 2006년 하반기에 20%로 증가했다가 2007년 상반기에는 7%로 감소했습니다.
그림 1 2007년 상반기에 집계된 전자 메일 감염 요인 통계
그림 1 2007년 상반기에 집계된 전자 메일 감염 요인 통계
Windows Live OneCare 및 Windows Live OneCare 보안 검사(safety.live.com)에서 수집한 원격 측정 데이터를 보면 2007년 상반기에 바이러스 감염률, 백도어, 암호 유출, 트로이 목마를 이용한 데이터 유출 건수가 증가했음을 알 수 있습니다.
MSRT는 고객 컴퓨터에 퍼져 있는 맬웨어를 찾아서 제거하도록 설계되었습니다. 이 도구는 주로 WU(Windows Update), MU(Microsoft Update) 및 AU(자동 업데이트)를 통해 중요 업데이트로 제공됩니다. 지난 2년 동안 전 세계 2,050만 대의 컴퓨터에서 MSRT를 사용하여 5,030만 개의 감염된 파일을 제거했습니다. 현재까지 MSRT가 실행된 횟수는 2007년 상반기에 실행된 19억 번을 포함하여 총 74억 번이 넘습니다.
MSRT는 Microsoft와 Microsoft 고객에게 데이터를 제공하는 중요한 소스입니다. MSRT에서 관찰된 감염률을 보면 이전 버전의 Windows 운영 체제에 비해 Windows Vista 및 Windows XP SP2 운영 체제의 감염률이 현저히 낮은 것을 알 수 있습니다(그림 2 참조). MSRT가 Windows Vista 컴퓨터에서 제거한 맬웨어는 Windows XP SP2 컴퓨터에 비해 60% 적은 수였고, 서비스 팩이 설치되지 않은 Windows XP 컴퓨터에 비해서는 91.5%나 적었습니다. 흥미롭게도 컴퓨터당 치료 횟수는 시간이 경과해도 일정했으며 감염된 컴퓨터당 평균 치료 횟수는 2.2회였습니다.
그림 2 2007년 상반기 MSRT를 통한 OS 버전별 맬웨어 제거 현황
그림 2 2007년 상반기 MSRT를 통한 OS 버전별 맬웨어 제거 현황
MSRT 참조 결과, 일반적으로 선진국보다 개발 도상국에서 더 많은 맬웨어가 발견된 것을 알 수 있었습니다. 예를 들어 유럽에서 감염률이 가장 높은 국가는 알바니아와 터키였고 감염률이 가장 낮은 나라는 이탈리아와 핀란드였습니다. 아시아 태평양 지역에서는 몽골과 태국이 감염률이 가장 높았고 뉴질랜드와 일본은 감염률이 가장 낮았습니다. 미국은 아메리카 대륙에 있는 대부분의 다른 국가 및 지역에 비해 감염률이 낮았으며 감염률은 세계 평균 정도였습니다. 평균적으로 MSRT는 2007년 상반기 동안 216대의 모든 컴퓨터에서 맬웨어를 하나씩 제거한 셈이 됩니다.
Windows Defender는 Windows Vista, Windows XP 및 Windows Server 2003에서 실행됩니다. 2007년 상반기 동안 Windows Defender를 통해 약 5,070만 개의 원치 않는 소프트웨어가 발견되었으며 Windows XP SP2 컴퓨터에 비해 Windows Vista 컴퓨터에서 발견된 개수가 2.8배 적은 것으로 나타났습니다. 마찬가지로 Windows Vista 컴퓨터에서 발견된 원치 않는 소프트웨어의 수는 Windows Server 2003 컴퓨터에서 발견된 수의 절반에 불과했습니다.
여러분은 이제 이러한 통계 결과에 흥미로움을 느낌과 동시에, 이를 활용하여 시스템 환경을 보호할 수 있는 방법에 대해 알고 싶어질 것입니다. 최신 버전의 SIR에는 각 단원의 주요 내용이 요약되어 있으며 "Strategy, Mitigations, and Countermeasures(전략, 완화 방법 및 대응 수단)"가 제시되어 있습니다. 이 목록을 통해 보고서에 있는 각 단원의 핵심 내용을 빠르게 파악할 수 있습니다.
더 나아가 SIR에서 제공하는 데이터와 견해, 그리고 지침을 통해 끊임없이 변화하는 위협 환경에 비추어 현재의 보안 상태를 평가하고 개선할 수 있습니다. 조사 결과를 바탕으로 전략, 완화 방법 및 대응 수단을 제공하는 전체 보고서는 microsoft.com/sir에서 다운로드할 수 있습니다.

Tim RainsMMPC(Microsoft Malware Protection Center)의 제품 관리자로, Microsoft SIR(보안 정보 보고서)의 프로덕션을 관리합니다. SIR의 저자는 Jeff Jones(Microsoft Trustworthy Computing Group 관리자), Jeff Williams(MMPC 관리자), Mike Reavey(Microsoft Security Response Center의 그룹 관리자), Ziv Mador(MMPC의 수석 프로그램 관리자 겸 응답 조정자)입니다.


 Networking: 원인을 파악하기 힘든 네트워크 문제 추적
Networking Christopher Stoneff

원인을 파악하기 힘든 네트워크 문제 추적
한 눈에 보기:
  • 네트워크 문제의 일반적인 원인
  • 밖으로 드러나는 요인 그 이상에 대한 검토
  • 문제 해결 도구가 도움이 되지 않을 때
  • 연결 제한을 구성해야 하는 이유

여러분은 시스템이 다른 시스템과 통신이 되지 않는데 그 이유는 알기 어려운 상황을 여러 번 경험했을 것입니다. 관리 시스템은 라우트된 네트워크의 한 세그먼트에 상주하며 Microsoft Internet Security and Acceleration(ISA) Server
또는 다른 하드웨어 장치 같은 라우터를 통해 다른 네트워크 세그먼트에 연결됩니다. 이 경우 10대나 20대 또는 100대의 시스템을 관리할 때는 아무런 문제가 발생하지 않습니다. 하지만 500대의 시스템을 관리하려고 하면 연결이 이미 열려 있는 컴퓨터를 제외한 네트워크의 다른 컴퓨터와 통신할 수 없게 됩니다. 여러분 자신은 다른 시스템과 통신하거나 인터넷에 연결할 수 없지만 여러분의 시스템이 속한 세그먼트의 다른 사용자를 포함하여 네트워크의 다른 사용자에게는 이러한 문제가 발생하지 않습니다. 이 경우 가장 먼저 어느 부분을 검토해야 할까요?

문제 진단
이러한 상황에서는 대개 관리 소프트웨어에 문제가 있다고 가정합니다. 대부분의 사전 대응적인 관리 도구는 관리자의 시스템에 연결하여 이를 관리하지만 때로는 추적하려고 하는 문제가 이러한 도구 자체로 인해 발생한 것일 수 있습니다. 이는 사전 대응적인 관리 도구가 더 나은 관리를 위해 사용자 장치에 대해 수천 개의 연결을 만들 수 있기 때문입니다. Windows®에서는 연결이 유휴 상태인 경우를 포함하여 연결을 기본적으로 2분 동안 열어 둡니다. 단, 도구, 응용 프로그램 또는 서비스에서 연결을 이보다 길게 유지하는 경우는 예외입니다. 따라서 관리 시스템에서 2분 동안 다른 시스템과 통신하지 않더라도 1,000개 이상의 연결이 열려 있을 수 있습니다. 명령 프롬프트에서 NETSTAT를 실행하면 열려 있는 연결을 볼 수 있습니다. NETSTAT 명령은 시스템의 열려 있거나, 보류 중이거나, 닫히고 있는 모든 연결과 연결의 상태를 보여 줍니다. 상태 메시지에 대한 설명은 RFC 793(tools.ietf.org/html/rfc793)을 참조하십시오.
오작동하는 관리 소프트웨어를 찾아내기 위해 원격 시스템에 연결하는 배치 파일을 만들 수 있습니다. 이 배치 파일을 실행하는 동안 같은 문제가 발생하면 관리 소프트웨어와 해당 스레드에는 문제가 없음을 알 수 있습니다. 다음은 배치 파일에 포함해야 할 내용에 대한 예제입니다.
Net use \\system01\ipc$ Net use \\system02\ipc$ Net use ...
문제의 관리 프로그램이 고유의 네트워킹 및 인증 스택을 구현하는 경우 이것이 원인일 수 있습니다. 하지만 대부분의 관리 패키지와 같이 에이전트가 없는 솔루션에서는 관리 도구가 운영 체제의 네트워킹 및 인증 스택을 사용하여 네트워크 작업을 수행합니다. 배치 파일도 운영 체제의 네트워킹 및 인증 스택을 사용합니다. 따라서 많은 네트워크 연결을 시작하는 배치 파일을 사용했을 때 오류가 발생하지 않는다면 프로그램에서 운영 체제의 네트워킹 및 인증 스택을 사용한 것 때문에 문제가 발생한 것이 아님을 알 수 있습니다.

로그 및 오류 메시지가 도움이 되지 않는 경우
연결이 실패하기 시작할 때 오류 53(네트워크 경로를 찾을 수 없습니다.), 오류 64(네트워크 이름이 삭제되었습니다.), 오류 1203(주어진 네트워크 경로를 사용할 수 있는 네트워크 공급자가 없습니다.) 등의 많은 오류 정보 메시지가 표시되었을 것입니다. 일반적으로 이러한 메시지는 모두 이름 확인 문제를 나타냅니다. 문제는 모든 시스템에서는 이름을 확인하고 동일한 시스템에 연결하는 데 아무런 문제가 없다는 것입니다. 시스템 설정에 문제가 없는지 확인하려는 경우 ipconfig를 실행하여 설정이 올바른지 확인할 수 있습니다.
이 문제가 관리 시스템에 국한된 문제로 보이므로 그 다음으로는 이벤트 로그를 검토해야 합니다. 응용 프로그램 로그는 검색해도 별 소득이 없습니다. 하지만 시스템 로그를 검색하면 최대 연결 수에 도달했음을 알려 주는 이벤트 원본 TCP/IP에서 발생한 경고 이벤트 4226을 찾을 수 있습니다(그림 1 참조).
그림 1 최대 한계에 도달한 TCP 연결
그림 1 최대 한계에 도달한 TCP 연결
Microsoft® Knowledge Base에서 연결 제한에 대해 검색해 보면 완료되지 않은 연결에 대해 적용되는 연결 제한은 있지만 완료된 연결에 대해 적용되는 연결 제한은 없다는 사실을 알 수 있습니다. HKLM\System\CurrentControlSet\Services\TCPIP 아래에 있는 다음 레지스트리 항목을 조정하여 앞서 언급한 최대 연결 수 등의 요소를 제어할 수 있습니다. TcpNumConnections는 TCP에서 동시에 열 수 있는 최대 연결 수(기본값은 10)를 설정하는 데 사용됩니다. TCPTimedWaitDelay는 연결이 닫힐 때 연결이 TIME_WAIT 상태에 있는 시간을 설정합니다. 기본 반감기(half-life)는 120초이며 이는 연결이 기본적으로 4분 동안 사용됨을 나타냅니다. 마지막으로, MaxFreeTcbs도 최대 연결 수를 제어하는 데 사용됩니다. 모든 TCP 제어 블록이 사용 중이면 TCPTimedWaitDelay가 아직 만료되지 않았더라도 TCP가 TIME_WAIT 상태인 것으로 표시된 연결을 해제하여 추가 연결을 만들어야 합니다. TCPTimedWaitDelay 값의 범위는 30-300초(0x1E–0x12C)입니다.
이러한 레지스트리를 변경하면 시나리오에 따라 전반적인 성능이 약간 향상될 수도 있습니다. 이러한 제한을 없애도록 TCPIP.sys 파일을 패치하는 방법도 시도해 볼 수 있지만 이 방법을 사용하는 경우 P2P 응용 프로그램에서만 성능이 개선됩니다.

네트워크 캡처
연결 문제를 해결하기 위한 다른 시도가 모두 실패할 경우 관련된 시스템에서 네트워크를 캡처하면 도움이 될 수 있습니다. 필자의 경우 Microsoft 네트워크 모니터(Netmon)를 실행한 결과 관리 도구 및 테스트 스크립트를 통해 얻은 것과 정확히 같은 결과를 보여 주는 캡처가 생성되었습니다. 즉, 모든 것이 순조롭게 작동하다가 오류가 발생했다는 어떠한 징후도 없이 작동하지 않게 되었습니다.
그림 2에서는 처음 n개 시스템 간의 성공적인 통신을 나타내는 Netmon 실행 결과를 보여 줍니다. 이 그림에서는 RPC 요청에 대한 승인을 받고 있습니다. 성공적인 양방향 통신을 나타내는 이러한 결과가 나타나야 합니다.
그림 2 Netmon에 나타난 성공적인 통신
그림 2 Netmon에 나타난 성공적인 통신
이제 관리 시스템 및 원격 시스템의 캡처를 검토해야 합니다. 이 캡처에서는 오류 53/1203을 보여 줍니다. 시스템에서 통신이 이루어지지 않으므로 검토할 수 있는 내용이 없습니다. 그림 3의 네트워크 캡처를 보면 관리 시스템에서 IP 주소를 확인하고 포트 445(Microsoft SMB 포트)를 통해 시스템에 연결하려고 시도하지만 응답을 받지 못합니다.
그림 3 응답을 받지 못한, 포트 445를 통해 시스템에 연결하려는 시도
그림 3 응답을 받지 못한, 포트 445를 통해 시스템에 연결하려는 시도
시스템에서 동시에 연결할 수 있는 것보다 많은 스레드가 실행 중일 때 표시되는 오류 메시지는 경우에 따라 다를 수 있습니다. 일부 경우, 이름은 확인되었지만 IP 주소를 찾을 수 없음을 나타내는 오류 53이 원본 시스템에서 표시될 수 있습니다. 이 오류는 DNS가 연결할 수 없는 주소를 제공하고 있음을 나타냅니다. 요청한 이름이나 IP 주소에 대해 응답한 시스템이 없음을 나타내는 오류 1203이 표시될 수도 있습니다. 이 경우 오류 1203은 DNS를 사용할 수 없음을 나타냅니다. nslookup을 실행하면 이 경우에 해당하는지 확인할 수 있습니다.
이때쯤이면 문제를 해결할 수 없다는 절망감이 들 수도 있습니다. 하지만 아직 시도해 볼 만한 옵션이 더 남아 있습니다. 대부분의 사용자는 밖으로 드러나는 문제만 보고 연결 인프라를 검토할 생각은 하지도 않습니다. 사용자 시스템이 네트워크의 나머지 부분에 연결할 수 없는 유일한 시스템이고 이벤트 로그에서는 사용자 시스템에서 허용되는 최대 연결 수에 도달했음을 보여 주므로 이 문제가 본질적으로 아키텍처와는 관련이 없어 보일 수도 있습니다.
관리 솔루션에서 생성한 수천 개의 연결이 동시에 시작되지는 않았더라도 전송 지속 시간과 연결 시간 제한으로 인해 특정 시점에 생각했던 것보다 많은 수의 연결이 열려 있을 수 있습니다. 따라서 네트워크의 다른 곳에 연결되는 시스템도 검토해야 합니다.
설명하면 이렇습니다. 앞에서도 언급했듯이 네트워크 트래픽은 네트워크를 경유할 때 스위치, 라우터 및 방화벽을 통과합니다. 이러한 지점 중 하나(일반적으로 라우터나 방화벽)에서 침입 검색 시스템을 만날 수 있습니다. 관리되는 스위치와 라우터의 경우 트래픽 필터링을 수행할 수도 있습니다. 이러한 장치를 관리하는 사람은 로그에서 오류 메시지나 경고 메시지를 확인해야 합니다. 바로 이러한 시스템 내부에 통신 문제의 원인이 있을 수도 있습니다.
현재는 내부 시스템에서 내부의 다른 시스템으로 연결하는 경우이므로, 해당 장치에 대해 경고가 구성되지 않았거나 문제가 침입 또는 DoS(서비스 거부) 공격으로 분류되지 않아서 경고가 생성되지 않았을 수 있습니다. 다시 한번 강조하지만 로그를 먼저 검토해야 합니다. 예를 들어 ISA Server의 경우 ISA Server 관리 콘솔의 Arrays\<ArrayName>\Monitoring\Logging에서 로그를 찾을 수 있습니다.
사용자를 차단하는 것이 정책이면 ISA Server의 경우 다음 결과 코드를 찾습니다. 여기서 원본 IP는 사용자의 관리 컴퓨터입니다.
  • 0xc0040037 FWX_E_TCP_RATE_QUOTA_EXCEEDED_DROPPED
  • 0xc004000d FWX_E_POLICY_RULES_DENIED
  • 0xc0040017 FWX_E_TXP_SYN_PACKET_DROPPED
이러한 결과 코드가 있으면 연결 문제의 근본 원인을 찾았다고 할 수 있습니다.

해결 방법 구현
문제가 무엇인지 찾아냈으므로 해결 방법은 간단합니다. 하지만 부서 정책에 가로막혀 구현이 어려울 수도 있습니다. 방화벽, 라우터 및/또는 침입 검색 시스템의 보안 구성에 예외를 두는 작업은 누구에게나 허용되는 작업이 아니므로 구성을 변경하려면 먼저 자신에게 적절한 권한이 있는지 확인해야 합니다.
다시 ISA Server의 예를 들면 다음 단계는 지정한 호스트 또는 네트워크의 모든 시스템에 대한 최대 연결 수를 늘리는 방법을 보여 줍니다(그림 4 참조). ISA Server 관리 콘솔을 열고 Arrays\<ArrayName>\Configuration\General\Configure Flood Mitigation Settings로 이동합니다.
그림 4 ISA Server를 사용하여 하나의 호스트 또는 모든 시스템에 대한 최대 연결 수 늘리기
그림 4 ISA Server를 사용하여 하나의 호스트 또는 모든 시스템에 대한 최대 연결 수 늘리기
여기서 주목해야 할 두 가지 설정은 IP 주소당 최대 TCP 동시 연결 수, 그리고 각 IP 주소에 대한 분당 최대 TCP 연결 요청 수입니다. IP 주소당 최대 TCP 동시 연결 수는 일반적으로 능동적인 관리 작업이 수행되지 않는 경우 충분하도록 설정됩니다. 즉, 단일 컴퓨터가 짧은 시간에 수천 대의 컴퓨터에 능동적으로 연결하는 상황을 감안하지는 않습니다. ISA Server의 경우 최대 TCP 동시 연결 수에 대한 기본 제한이 160입니다. 각 IP 주소에 대한 분당 최대 TCP 연결 요청 수는 네트워크 손상을 방지하고 네트워크 검사 내용의 표시를 제한하기 위한 것입니다. 기본 제한은 각 IP 주소에 대해 분당 600개의 연결 요청입니다.
앞에서 설명했듯이 다른 서비스나 응용 프로그램에서 연결을 지속하려고 시도하지 않는 한 Windows에서는 연결이 유휴 상태인 경우를 포함하여 기본적으로 2분 동안 연결을 지속합니다. 즉, 컴퓨터에 대한 관리 작업이 성공적으로 완료되었고 더 이상 컴퓨터와 통신할 필요가 없더라도 연결이 활성 상태로 남아 있을 수 있습니다. 이러한 열려 있는 연결 수는 허용되는 총 연결 수에 포함됩니다. 연결을 제거하지 않고 이 프로세스를 160회 이상 반복하면 라우터에서 모든 연결 시도를 거부하는 것을 확인할 수 있습니다. 관리 프로그램에서 적극적으로 세션을 종료하더라도 Windows에서는 대상 시스템이 세션 연결을 끊는 데 동의할 때까지 연결을 time_wait 상태로 둘 수도 있습니다.
문제의 원인일 확률이 가장 높은 IP 주소당 최대 TCP 동시 연결 수부터 조정하십시오. 이 값은 관리 시스템에서 다른 시스템을 관리하는 데 필요한 모든 연결을 설정하더라도 액세스 거부가 발생하지 않는 수준으로 설정해야 합니다. 이 설정 옆의 Edit(편집) 단추를 클릭하고 값을 변경합니다.
다음 메시지(그림 5 참조)에는 모든 클라이언트에 적용되는 기본 제한을 나타내는 Limit(제한) 상자가 있습니다. Custom limit(사용자 지정 제한)은 Flood Mitigation(서비스 장애 완화) 대화 상자의 IP Exceptions(IP 예외) 탭에 정의된 모든 시스템과 네트워크 등에 적용됩니다. 모든 시스템이 추가 연결을 만들 수 있도록 허용하려면 Limit(제한) 값을 변경합니다. 관리 시스템에 대해서만 예외를 설정하려면 Custom limit(사용자 지정 제한) 값을 조정하고 관리자의 시스템을 IP Exceptions(IP 예외) 탭에 추가합니다. 대개는 관리자의 시스템에 대해서만 예외를 허용하는 것이 좋습니다.
그림 5 기본 연결 제한 및 사용자 지정 연결 제한
그림 5 기본 연결 제한 및 사용자 지정 연결 제한
사용자 지정 제한 값을 특정 시스템에 대해서만 변경하려면 Custom limit(사용자 지정 제한) 필드의 값을 변경한 다음 OK(확인)를 클릭합니다. 그런 다음 관리자의 시스템을 Flood Mitigation(서비스 장애 완화) 대화 상자의 IP Exceptions(IP 예외) 탭에 추가합니다. 단일 컴퓨터를 예외 목록에 추가하려면 IP Exceptions(IP 예외) 탭에서 Add(추가)를 클릭하여 Computer Sets(컴퓨터 집합) 대화 상자를 표시합니다. New(새로 만들기)를 클릭하여 관리자 시스템이 포함될 새 네트워크 집합을 만듭니다(없는 경우). 이 네트워크 집합을 선택하고 Add(추가)를 클릭하여 Internal Networks(내부 네트워크) 네트워크 집합에 추가한 다음 Close(닫기)를 클릭합니다. 다시 Internal Networks(내부 네트워크) 네트워크 집합을 선택하고 Edit(편집)을 클릭합니다. 그러면 Internal Networks properties(내부 네트워크 속성)(그림 6 참조) 대화 상자가 열립니다. 이 대화 상자에서 Add(추가)를 클릭하여 컴퓨터, 주소 범위, 서브넷을 추가할 수 있는 하위 메뉴를 표시하고 컴퓨터를 선택합니다. 나중에 이 항목을 검토하는 사람이 관리자의 시스템을 제거하지 않도록 해당 항목을 나타내는 이름, 시스템의 IP 주소 및 설명을 입력합니다(그림 7 참조). OK(확인)를 클릭하여 시스템을 추가하고 다시 OK(확인)를 클릭하여 예외를 추가합니다. 이러한 변경을 모두 수행했으므로 이제 설정을 적용해야 합니다.
그림 6 내부 네트워크 속성 설정
그림 6 내부 네트워크 속성 설정
그림 7 시스템이 제거되지 않도록 컴퓨터 이름, IP 주소, 설명 입력
그림 7 시스템이 제거되지 않도록 컴퓨터 이름, IP 주소, 설명 입력
사전 대응적 관리 도구를 다시 실행해 보십시오. 그러면 성능이 향상되고 연결이 실패하지 않을 것입니다. 적어도 네트워크 트래픽으로 인해 연결이 실패하지는 않을 것입니다. 결국 소프트웨어에서 시작한 연결 수가 아니라 연결 수를 적절히 계획하지 않아서 연결 중단 문제가 발생했음을 알 수 있습니다.

교훈
IT 부서가 겪는 가장 골치 아픈 문제 중 하나가 바로 원인을 파악하기 어려운 문제가 발생할 경우 이를 해결하는 것입니다. 이러한 것들은 최종 사용자가 발생시키거나 서버 팀에서 원인을 제공하거나 지원 부서에서 인식하고 있는 유형의 문제가 아니므로 안타깝게도 관리자가 직접 문제를 해결해야 합니다. 문제를 파악하여 해결하는 데 사용할 수 있는 많은 도구가 있지만 도구만으로는 충분하지 않을 때가 있습니다. 도구로 문제를 올바르게 해결할 수 없을 때도 있고 도구보다 나은 방법이 필요한 경우도 있습니다.
향후에 네트워크의 수많은 시스템 중에서 뚜렷한 이유 없이 자신의 시스템만 연결되지 않는 문제가 발생하면 이 문서에 설명된 단계를 수행해 보십시오. 이러한 단계를 따르면 관리 소프트웨어를 주의 깊게 검토하고 허용되는 연결 수를 적절히 설정하여 문제를 성공적으로 해결할 수 있을 것입니다.

Christopher Stoneff는 Lieberman Software(liebsoft.com)의 제품 관리자이자 보안 및 시스템 관리 소프트웨어 개발자입니다. Chris는 많은 IT 자격증을 소지하고 있으며, 그의 이러한 추진력을 뒷받침하는 가장 큰 힘은 어떤 일이 특정한 방향으로 일어나는 방식뿐만 아니라 그 이유에 대해서까지 알아내고자 하는 열정입니다.


 From the Editor: 대화를 시작합시다!
From the Editor
대화를 시작합시다!
Joshua Hoffman

거의 모든 중요한 사건들은 대화로 시작되었습니다.
"지구가 평평하다고 생각하지 않습니다. 직접 확인해 봐야 하지 않을까요?"
"달에 사람을 보내는 것이 어떨까요?"
"이 새 PC에 대한 의견이 있는데 얘기해 봐도 될까요?"
"만나서 커피 한잔합시다."
사실 마지막의 것은 그다지 중요한 사건은 아니지요... 그냥 제가 커피를 아주 좋아할 뿐입니다. 하지만, 만나서 커피 한잔하다 보면 좋은 아이디어가 떠오를 수도 있습니다.
어쨌든, 중요한 모든 사건은 대개 대화로 시작되었다는 생각이 이달 들어 저에게 두 가지 측면에서 새삼 진실로 다가옵니다. 첫 번째는 현재 블로그에서, 복도에서, 그리고 이번 호 TechNet Magazine(91페이지 Romi Mahajan의 Field Notes 칼럼 참고)에서 실제 벌어지고 있는 대화와 관련됩니다. 이는 소비자 주도의 IT에 관한 것이며 우리가 작업 현장에서의 IT 전문가에 국한되지는 않는다는 개념에 초점을 두고 있습니다. 우리의 일상 생활(자원 봉사 활동, 노래방에서 노래 부르기, Xbox로 게임하기 등)이 직장에서의 업무와 의사 결정에 영향을 미치는 것이 현실입니다. Romi와 저는 라스베이거스에서 곧 열릴 Windows Connections 회의에서 "대체 가능한 미래(The Fungible Future)"라는 주제로 특별 게스트 몇 분과 함께 이 대화를 계속 진행할 예정입니다. 여러분도 이 토론회에 직접 참관하시거나 웹 사이트(WeWantToKnow.net)를 통해 확인하시기 바랍니다. 그리고 저희 블로그(blogs.technet.com/tnmag)에서 진행되는 대화에 기탄없이 의견을 올려주시기 바랍니다. 저희는 여러분의 의견을 기다리고 있습니다.
두 번째는 이러한 대화를 가능하게 하기 위해 사용하는 기술에 관한 것입니다. 이번 호 TechNet Magazine에서는 복도 건너편에 있든 지구 반대편에 있든 더 쉽게 연락할 수 있게 해 주는 Exchange Server의 향상된 주요 기능에 대해 다루고 있습니다. Exchange Server 2007 SP1의 향상된 기능, 대기 연속 복제 기능이 재해 복구 계획을 어떻게 획기적으로 강화시켜주는지, Windows Server 2008에서 Exchange 플랫폼이 어떻게 향상되는지, 통합 메시징이 사용자들의 대화를 얼마나 편리하게 해 주는지 등을 확인할 수 있을 것입니다. 그리고 이번 호의 특별 보너스로, TechNet Magazine 인쇄 버전에는 객원 편집자인 Astrid McClean과 Martin McClean의 인기 포스터 시리즈 최신작이 들어 있습니다. 이들의 수상작인 Active Directory Component Jigsaw 포스터나 본지에 실렸던 Windows Server 2008 포스터를 보셨을 것입니다. 이번 호에서는 이들이 Exchange를 다뤘습니다. 자, 대화를 시작합시다. —Joshua Hoffman

도움을 주신 Ed Banti, Anah Cameron, Chun Yong Chua, Cliff Didcock, Jeremy Kelly, Michael Murgolo, Jon Orton, Jeff Ressler, Kevin Sullivan, Jim Truher, Scot Vidican, Michael Wilson을 비롯한 Microsoft 기술 전문가들에게 감사를 드립니다.

Joshua Hoffman


 Letters: 독자의 목소리
Letters
독자의 목소리

PageDefrag 유틸리티
2007년 9월호에서 다룬 SysInternals PageDefrag 유틸리티를 실행해봤습니다. 그러나 Windows Vista® x64에서는 "Make sure that you are an administrator. Error loading PageDefrag driver.(사용자가 관리자 권한을 가지고 있는지 확인하십시오. PageDefrag 드라이버 로드 중 오류가 발생했습니다.)"라는 오류 메시지가 나타나면서 실행이 되지 않습니다.
—Alex D.

현재 Windows Vista에서는 PageDefrag 유틸리티가 지원되지 않습니다. 이 유틸리티는 Windows NT® 4.0, Windows® 2000, Windows XP, Windows Server® 2003에서만 작동됩니다. 9월호 기사에서 이 사실이 분명히 표현되지 않은 점을 사과 드립니다.

백업 스케줄러
2007년 9월호 기사 "Windows Vista 백업 기술"을 아주 흥미롭게 읽었지만 몇 가지 의문이 있습니다. 그림 2에 보면 다음 백업의 날짜와 시각이 표시되어 있습니다. 백업 도구에 자체 스케줄러가 없는데 어떻게 그런 항목이 표시될 수 있을까요?
디스크 블록의 변경 사항을 기준으로 백업 대상이 결정되는데, 디스크 조각 모음을 실행하면 어떻게 되는 건가요? 블록이 이동되거나 변경되었으므로 데이터가 대량으로 백업되는 것인가요? 또한 복원 도중 블록이 원래의 위치로 복원될 경우 디스크 조각 모음은 어떻게 됩니까?
—Bruce G.

해당 기사의 저자인 Christine Fok의 답변은 다음과 같습니다.
그림 2에는 다음 파일 및 폴더 백업의 날짜와 시간이 표시되어 있지만 그것은 가장 최근의 Complete PC 백업 시각일 뿐입니다. 파일/폴더 수준의 백업 일정을 정할 수 있지만, 지적하신 바와 같이 Complete PC 백업에는 자체 스케줄러가 없습니다.
2회의 Complete PC 백업 사이에 조각 모음을 실행하면 두 번째 백업 크기가 더 커질 수 있다는 지적은 맞습니다. 그리고 조각 모음 이후의 복원에 대한 의문도 정당합니다. Complete PC는 파일 시스템 아래인 볼륨 수준에서 작동합니다. 따라서 백업 수행 이후 조각 모음 실행 여부에 관계없이 모든 블록을 백업 시점과 동일한 상태, 동일한 위치로 돌려 놓습니다. 그러므로 복원이 완료된 후에는 해당 볼륨에 조각 모음을 다시 실행해야 합니다.

BGInfo 도구
2007년 8월호의 Utility Spotlight 칼럼을 아주 재미있게 읽었습니다. 그 중에도 CPU 및 네트워크의 중요 정보를 수집하는 SysInternals의 BGInfo 도구에 관한 내용이 특히 훌륭했습니다. 저는 새로운 제품과 유틸리티, 프로그램 또는 응용 프로그램을 개발하는 사람들에 관한 기사를 흥미롭게 읽는 편입니다. Cogswell 씨가 개발한 다른 Microsoft 소프트웨어 제품이 또 있습니까?
—Daryl B.

BGInfo 유틸리티가 유용하다는 의견을 주셔서 매우 기쁩니다. Bryce Cogswell은 Sysinternals에서 Mark Russinovich와 공동 작업을 통해 사용하기 편리한 유틸리티를 많이 개발해 왔습니다. Microsoft는 2006년에 Sysinternals를 인수했고 Cogswell 씨와 Russinovich 박사는 현재 Microsoft에서 근무하고 있습니다. Sysinternals 웹 사이트(microsoft.com/technet/sysinternals)를 방문하면 원하는 모든 유틸리티를 참조하실 수 있습니다.

RPC와 방화벽
2007년 7월호에 실린 "RPC 오류 문제 해결" 기사는 많은 도움이 되었지만 한 가지 중요한 사항이 빠져 있었습니다. Windows 방화벽도 RPC 오류를 일으킬 수 있습니다. Windows 방화벽이 PING 요청은 허용하되, 요청되지 않은 수신 메시지를 허용하지 않도록 구성되어 있는 경우 원격으로 컴퓨터를 관리하려는 모든 시도는 실패하게 됩니다. Windows Resource Kit에서 RPCPING.exe를 실행하면 1722번 오류(RPC 서버를 사용할 수 없습니다)가 발생합니다.
이 경우, 방화벽은 방화벽으로서의 역할을 정확히 수행하게 됩니다. 즉 외부자가 시스템에 접근하는 것을 차단합니다. 그러나 이렇게 하면 관리자가 엔터프라이즈 네트워크의 컴퓨터를 관리하고자 할 때도 문제가 발생하게 됩니다.
—Aaron M.

RPC 문제의 다른 가능성을 지적해 주셔서 감사합니다. 해당 기사에 언급된 도구를 통해 이러한 문제를 해결할 수 있기를 바랍니다.

Windows XP 라이선스
2007년 10월호 Field Notes에서 Windows XP 라이선스를 불과 5달러에 구입할 수 있다는 내용을 보았습니다. 저희 회사는 비영리 출판사인데 그와 같은 혜택을 받을 수 있는지 궁금합니다. 전화나 우편을 통해서도 가능할까요? 전자 메일이 있긴 하지만 인터넷을 사용할 수 없는 상황입니다.
—Ernest B.

전자 메일 communitymar@techsoup.org 또는 전화 800-659-3579 x350를 통해 MAR 관리 파트너, TechSoup에 문의하실 수 있습니다. 우편 연락처는 다음과 같습니다. Community MAR Administrator, TechSoup Stock, 435 Brannan Street #100, San Francisco, CA 94107


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

네트워크 모니터 시스템
ActiveXperts Network Monitor
activexperts.com
시스템 관리자라면 어떤 문제가 발생했을 때 이 사실을 사용자보다 먼저 발견하는 것이 좋을 것입니다. 사용자들이 벌떼처럼 들고 일어나기 전에 말이지요. 서비스 모니터링은 인프라를 유지 관리하는 데 필요한 핵심 도구입니다. ActiveXperts Network Monitor는 LAN/WAN 및 Windows®, Novell, *NIX 서버를 모두 검사할 수 있는 다양한 검사 기능이 포함된 강력한 솔루션으로, 관리자는 이를 통해 사용자들이 문제를 보고하기 전에 어떤 문제가 발생했는지 확인할 수 있습니다.
ActiveXperts Network Monitor는 모니터링 스테이션으로 지정한 컴퓨터에서 서비스로 실행되는 Windows 기반 응용 프로그램입니다. 컴퓨터의 기반 운영 체제로 Windows 2000, Windows Server® 2003, Windows XP 또는 Windows Vista®가 지원됩니다. 프로그램이 설치되면 빠른 구성 마법사가 전자 메일 알림, SMS 알림, 기본 검사 주기 또는 실패 임계값 설정에 대해 안내합니다. 또한 실제 구성에서 예제로 사용할 수 있는 몇 가지 샘플 검사를 추가할 수 있습니다. 이렇게 하면 문제 발생을 미연에 방지할 수 있으며 응용 프로그램의 다양한 기능을 시스템 환경의 요구 사항에 맞게 구성하는 방법을 익힐 수도 있습니다.
이 응용 프로그램은 다음과 같은 세 가지 구성 요소로 나뉩니다. Network Monitor Engine은 모니터링 작업을 지속적으로 실행하는 Windows 서비스이며, Network Monitor Manager는 현재 모니터링 작업 확인, 작업 결과 확인, 구성 변경 등의 작업을 수행할 수 있는 Windows 응용 프로그램입니다. 세 번째 구성 요소인 웹 인터페이스는 작업 및 작업 결과를 읽기 전용으로 액세스할 수 있는 구성 요소입니다.
Network Monitor Engine은 모니터링 검사를 실행하는 외에 알림, 결과로 인해 실행되는 작업, 응용 프로그램에 대한 로깅 등의 작업도 처리합니다. 모니터링 엔진은 다중 스레드로 되어 있어 사용 환경에 맞게 확장이 용이합니다. 이 서비스는 모니터링 검사를 실행하기 위해 끝점 에이전트를 필요로 하지 않지만 원격 Windows 서버 또는 워크스테이션을 모니터링하려면 관리자 자격 증명을 제공해야 합니다. 그러나 다행히 자격 증명 모음을 여러 개 지정할 수 있으므로 여러 도메인과 보안 컨텍스트에 걸쳐 모니터링을 할 경우에도 모니터링 솔루션 실행을 위해 모든 권한을 가진 단일 계정이 필요하지 않습니다.
모니터링을 위해 가장 많이 시간을 할애해야 하는 구성 요소는 아마도 Network Monitor Manager일 것입니다. 이 구성 요소는 모든 기능, 구성 설정 및 성능을 세밀하게 제어할 수 있습니다. 여기에서 모니터링 작업을 트리 폴더 구조로 구성할 수 있습니다. 이렇게 하면 대규모 환경에서 원하는 항목을 보다 빠르게 찾고 확인할 수 있을 뿐 아니라 현재 UI 보기를 필터링하여 여러 모니터링 작업을 한눈에 파악할 수 있습니다.
아주 간단한 방법으로 새 모니터링 검사를 추가할 수 있습니다. Network Monitor에서는 IP 및 프로토콜 검사(예: ICMP, LDAP, SMTP, HTTP), Windows 검사(예: CPU, 프로세스, 메모리, 터미널 서버 검사), ODBC 연결, Oracle TnsPing, OLEDB 쿼리 기반 데이터베이스 검사, Novell 구성원 자격 검사, *NIX RSH 검사를 비롯한 약 40개의 검사를 기본적으로 제공합니다. 또한 네트워크에서 SensaTronics 환경 모니터링을 사용하여 온도, 습도와 같은 세부적인 환경 요소도 모니터링할 수 있습니다.
이 응용 프로그램은 사용자 지정 VBScript 및 Remote Shell 스크립트를 지원하므로 관리자가 원하는 대로 모니터링 작업을 구성할 수 있습니다. 또한 바이러스 백신 프로그램, Microsoft® ISA Server, XML 쿼리와 같은 다양한 서비스를 모니터링하기 위한 VBScript 템플릿 모음이 제공되므로 관리자는 이를 바탕으로 사용자 지정 모니터링 작업을 생성할 수 있습니다.
각 작업에 대해 검사 주기 및 실패 임계값을 설정할 수 있으며 필요한 경우에 지정된 날짜와 시간에 검사가 실행되도록 예약할 수도 있습니다. 예를 들어 로그 보관 작업이나 IIS 응용 프로그램 풀 재설정 같은 실행 프로세스의 결과를 확인하는 데 예약 검사를 사용할 수 있습니다. 검사가 실패하거나 복구된 경우 다시 부팅하거나 지정된 서비스를 재시작할 수 있을 뿐 아니라 실행할 실행 파일, 스크립트 및 일괄 작업을 지정할 수 있습니다. 마지막으로, 웹 인터페이스를 통해 XSL로 변환된 XML 결과 데이터를 볼 수 있습니다. 원하는 대로 스타일시트를 변형할 수 있어 NOC(Network Operations Center)나 모바일 장치를 위한 사용자 지정 보기를 만들 수 있으며 데이터가 XML로 되어 있어 다른 응용 프로그램이나 집계 시스템에서 데이터를 쉽게 검색할 수 있습니다.

가격: 서버 5대 라이선스당 $395부터입니다.
처음부터 사용할 수 있는 샘플 검사를 포함하는 ActiveXperts Network Monitor
처음부터 사용할 수 있는 샘플 검사를 포함하는 ActiveXperts Network Monitor

서평
Windows Vista Resource Kit
microsoft.com/mspress/books/9536.aspx
점점 더 많은 조직에서 인프라에 Windows Vista 클라이언트를 도입하게 됨에 따라 IT 전문가 역시 새로운 운영 체제에서 사용 가능한 도구를 신속하게 제공해야 할 필요성이 늘고 있습니다. 새로 출간된 Windows Vista Resource Kit(Microsoft Press®, 2007)에서는 엔터프라이즈의 Windows Vista 클라이언트에 구현해야 하는 다양한 정보 및 도구에 대한 내용을 다루고 있습니다. 설치 자동화 및 볼륨 정품 인증에서부터 데스크톱 관리 및 유지 관리, IPv6 네트워킹 및 원격 지원에 이르는 모든 내용이 포함되어 있습니다. 1,568페이지에 달하는 본문 내용 이외에도 100개 이상의 관리 및 배포용 스크립트, 디버깅 도구 모음, Solution Accelerator for Business Desktop Deployment(BDD) 및 기타 유용한 항목이 포함된 지원 DVD가 부록으로 제공됩니다.
이 책의 도입부에서는 Windows Vista의 새로운 기능을 개괄적으로 설명하며 UAC(사용자 계정 컨트롤), BitLocker 드라이브 암호화, DEP(데이터 실행 방지)와 같은 개선된 보안 기능을 상세하게 설명합니다. 또한 서비스 강화 및 커널 패치 보호의 개념에 대해서도 다룹니다. 또한 Windows 배포에 대해 살펴보고, 여러 가지 도구를 원하는 대로 사용하여 프로세스를 자동화할 수 있는 방법을 알아봅니다. 예를 들어 이 책에서는 Windows PE 2.0 사전 설치 및 복구 환경 구성에 대해 살펴보고, 엔터프라이즈에서 Windows Vista를 계획 및 배포할 때 활용할 수 있는 BDD 2007에 대해 심층적으로 알아봅니다. 뿐만 아니라 디스크 이미지를 생성 및 구성하는 데 사용할 수 있는 최상의 방법을 제공하며, Windows 사용자 환경 전송 및 사용자 환경 마이그레이션 도구를 사용하여 사용자의 데이터를 마이그레이션하는 방법에 대해서도 설명합니다.
그 다음에는 새 ADMX(XML 기반 관리 템플릿 파일)에 대해 자세히 다룸으로써 그룹 정책을 통한 데스크톱 환경 관리에 대해 살펴봅니다. 디스크 및 파일 시스템 관리와 Windows Vista의 향상된 기능인 ReadyBoost 및 BitLocker에 대해서도 다룹니다. 그리고 이전 버전과 섀도 복사본, 디스크 할당량의 작동 원리를 설명한 다음 작업 그룹, 도메인, 애드혹 무선 환경에서 Windows Meeting Space를 배포 및 관리하는 방법에 대해서도 알아봅니다.
Desktop Maintenance(데스크톱 유지 관리) 단원에서는 Windows 오류 보고, 성능 모니터링, Windows 이벤트와 같은 작업에 대해 설명하며 지원 부서에서 원격 지원 기능을 활용할 수 있는 방법에 대해서도 설명합니다. 그 다음으로 감사 도구와 소프트웨어 업데이트, BITS(Background Intelligent Transfer Service), Windows Update에 대한 내용을 다룹니다.
Networking(네트워킹) 단원에서는 Windows 방화벽의 세부적인 작동 원리에 대해 알아보고 네트워킹 스택의 새로운 개선 사항을 설명합니다. 원격 데스크톱 및 VPN 연결을 사용하여 원격 사용자 및 네트워크를 구성하는 방법에 대해서도 알아봅니다.
마지막으로 부팅에서부터 네트워크, 드라이버 오류, 장치 문제에 이르는 여러 가지 문제 해결 정보를 다룹니다. 일부 내용에서 잘 알려지지 않은 마케팅 관련 용어가 나올 수 있으나 1,500페이지에 달하는 내용이 모두 이런 용어로 되어 있지는 않습니다. 본 서적은 Windows Vista 및 해당 도구, 이 운영 체제의 관리 방법에 대해 심층적이고 광범위한 내용을 다루고 있습니다.

가격: $59.99

HTTP 트래픽 분석
Charles Web Debugging Proxy
xk72.com/charles
응용 프로그램과 워크스테이션, 서버 및 인터넷 간에 HTTP 기반 통신량이 늘어나는 것을 고려할 때 관리자에게는 성능 좋은 HTTP 트래픽 분석기가 무엇보다도 절실할 것입니다. 이러한 도구를 사용하면 프록시 문제, 보안 문제, 연결 오류, 구성 문제, 응용 프로그램 간의 통신 문제를 확인할 수 있습니다. 필자가 추천하고자 하는 도구는 Karl von Randow의 자바 기반 응용 프로그램인 Charles Web Debugging Proxy입니다.
다른 디버깅 프록시와 마찬가지로 이 응용 프로그램은 "중재자"와 같은 역할로 설정됩니다. 즉, 끝점 응용 프로그램의 사이에 위치하여 확인되는 트래픽을 가로채 해석합니다. 이러한 구성 덕분에 이 응용 프로그램을 사용하면 암호화된 HTTPS 트래픽을 해독하여 일반 텍스트 형식으로 볼 수 있습니다. UI 메뉴에는 보기 좋게 정리된 기록 세션이 있습니다. 이 세션에서는 이미지, 스크립트, 스타일시트 및 페이지에 대한 기본 요구 사항에서부터 크기, 대기 시간, 타이밍에 이르는 중요한 세부 정보를 참조할 수 있습니다. 또한 각 요청에 대해 어떤 쿠키를 보내고 받았는지 확인할 수 있고, 쿠키에 포함된 내용을 확인할 수 있으며 모든 쿠키를 차단할지 여부도 선택할 수 있습니다.
Charles Web Debugging Proxy를 사용하면 '304 Not Modified' 응답의 최종 수정 날짜를 확인하거나 응용 프로그램을 통해 이동할 때 관련 요청 및 응답에서 캐시 관련 헤더를 제거하여 캐시가 사용되지 않도록 설정함으로써 요청 캐시 문제를 해결할 수 있습니다. 실제로 이 응용 프로그램의 다시 쓰기 설정을 사용하면 규칙 모음을 정의하여 요청 및 응답이 응용 프로그램을 통과할 때 HTTP 헤더 또는 본문 내용을 다시 쓰도록 할 수 있습니다. 또는 이 응용 프로그램의 DNS 스푸핑 설정을 사용하여 호스트의 IP 주소를 덮어쓰고 DNS에 등록되어 있지 않을 수 있는 항목에 대한 요청을 테스트할 수 있습니다. 이러한 기능은 테스트를 수행할 때 매우 유용합니다. 예를 들어 새 웹 서버를 실행하기 전에 해당 웹 서버가 호스트 헤더를 제대로 수신하고 응답하고 있는지 확인할 수 있습니다.
이 도구를 사용하여 AJAX 요청 및 응답을 디버깅하고 응답 내의 원시 XML 데이터를 살펴볼 수도 있습니다. UI에서 텍스트의 원시 요청 및 응답 데이터를 확인할 수 있으며 잘못된 헤더 부분을 찾을 수 있습니다.
이 도구에서는 데이터 트랜잭션을 확인하는 데 매우 유용한 두 가지 데이터 레이아웃을 제공합니다. Summary 테이블과 Chart 테이블이 바로 그것입니다. Summary 테이블에는 헤더 크기, 본문 크기, 응답 시간, 응답 코드, MIME 형식, 리소스 등이 표시되며 이 테이블을 이용하면 요청/응답 데이터를 신속하게 확인할 수 있습니다. 이와 달리 Chart 테이블에서는 수명 주기 일정을 그래픽으로 제공합니다. 이를 통해 어느 때에 요청/응답 데이터가 발생했으며 트랜잭션에 소요된 시간은 어느 정도인지 확인할 수 있습니다.
또한 기록 세션을 저장하여 나중에 다시 재생 및 분석할 수 있습니다. 이렇게 하면 산발적인 통신 오류를 유발하는 복잡한 요청/응답 흐름을 쉽게 캡처할 수 있습니다. 한번 저장한 세션은 복제할 수 있으며 현재 세션을 CSV 또는 HTTP 추적 형식으로 내보내는 것은 물론 HTTP 추적 파일을 새 세션으로 가져올 수도 있습니다.
낮은 대역폭에서 요청을 시뮬레이션하는 경우(예: 기업 네트워크가 아닌 56k 모뎀을 통한 요청이 실패한 원인을 찾아내려는 경우) 이 응용 프로그램에서는 일반적인 사전 설정 모음을 선택하거나 대역폭, 사용률, 왕복 대기 시간, MTU(최대 전송 단위)의 네 가지 제한 요소를 기준으로 새로운 사전 설정을 정의할 수 있도록 하는 제한 기능을 제공합니다. 또한 로컬 포트를 원격 끝점(포트)에 바인딩함으로써 포트에 전송된 모든 트래픽이 원격 주소로 리디렉션되도록 역방향 프록시 또는 포트 전달기와 같은 역할을 하는 디버깅 프록시를 구성할 수도 있습니다.

가격: 단일 사용자 라이선스의 경우 $50부터입니다.
HTTP 트래픽을 분석하는 Charles Web Debugging Proxy
HTTP 트래픽을 분석하는 Charles Web Debugging Proxy

불필요한 파일 제거하기
Wise Disk Cleaner 2
wisecleaner.com
하드 디스크는 마치 집과 같습니다. 시간이 지날수록 물건이 쌓이고 실제로 필요하지도 않은 것들을 계속 보관해 두게 되니 말입니다. 때로는 약간의 시간을 들여 잡동사니를 치워버리는 것이 좋습니다. 하드 디스크를 정리하는 기본적인 방법에는 시스템 도구, 디스크 정리, 검색 기능과 같은 기본 제공되는 Windows 도구를 사용하여 정리하는 방법이 있습니다. 그러나 사용하기 쉽고 빠른 유틸리티를 활용할 수도 있습니다. 무료로 제공되는 것이라면 더할 나위 없겠죠. 여기에 딱 들어맞는 도구가 바로 Wise Disk Cleaner 2입니다. Wise Disk Cleaner 2를 사용하면 하드 디스크에서 문제를 일으키는 성가신 파일을 검색하여 시스템에서 안전하게 제거할 수 있습니다.
이 도구의 장점 중 하나는 검색된 모든 파일이 UI에 표시되므로 잠재적인 문제를 식별하기 용이하다는 점입니다. 또 다른 유용한 기능으로는 검사 및 제거할 추가 파일 유형을 쉽게 추가할 수 있다는 점을 들 수 있습니다. Wise Disk Cleaner를 사용하면 원하는 경우 임시 인터넷 파일을 지울 수 있고 쿠키 보관 여부도 선택할 수 있으므로 저장된 사이트 설정을 그대로 유지할 수 있습니다. 또한 Windows Update 원본, 최근에 사용한 파일 목록, Windows 및 사용자 임시 폴더는 물론 Windows Update 설치 제거 파일도 제거할 수 있습니다. 응용 프로그램을 자동으로 실행할 수 있으며, 기본 설정에서 항목을 영구적으로 삭제할지 아니면 휴지통에 버릴지도 설정할 수도 있습니다. 이 프로그램은 추후 확인을 위해 프로그램의 작업을 기록합니다.

가격: 무료
안전하게 삭제할 수 있는 파일을 검색하는 Wise Disk Cleaner 2
안전하게 삭제할 수 있는 파일을 검색하는 Wise Disk Cleaner 2

네트워크 장치 관리
iReasoning Networks MIB Browser Personal Edition
ireasoning.com/mibbrowser.shtml
SNMP(단순 네트워크 관리 프로토콜)를 사용하는 네트워크 장치, 응용 프로그램, 시스템이 인프라에 있는 경우 iReasoning Networks MIB Browser를 사용하면 Windows 탐색기와 유사한 보기를 통해 MIB(관리 정보 데이터베이스) 파일 모음을 로드하고 계층적 구조에서 필요한 항목을 검색할 수 있습니다. 여기에서 OID(개체 ID), 구문, 읽기/쓰기 액세스, 설명을 비롯한 선택된 개체의 세부 정보를 확인할 수 있습니다.
SNMP 요청을 실행하여 UI를 통해 네트워크 장치의 데이터를 쉽게 검색할 수 있습니다. 단지 장치의 IP 주소를 입력하고 MIB 개체를 선택한 다음 Go를 클릭하기만 하면 됩니다. 필요한 경우 포트, SNMP 요청 버전, 읽기 및 쓰기 커뮤니티 문자열을 설정할 수도 있습니다. 장치에서 허용하는 경우에는 에이전트를 변경하는 것도 간단합니다. OID, 데이터 유형, 값을 선택한 다음 OK를 클릭하기만 하면 됩니다. 또한 기본 제공 Trap Sender 및 Trap Receiver 유틸리티를 사용하면 트랩을 실행하고 트랩 작업을 검토할 수 있으며, 트랩 작업에 필터를 적용하면 문제가 있는 장치를 수월하게 확인할 수 있습니다.
iReasoning Networks MIB Browser Personal Edition은 무료로 제공됩니다. 그러나 이 버전에서는 SNMPv3이 지원되지 않으며 동시에 로딩할 수 있는 MIB는 다섯 개로 제한됩니다. 라이선스당 $269의 가격으로 구입할 수 있는 Professional Edition에는 부가 기능이 포함되어 있으며 SNMPv3, 네트워크 검색, 장치 비교 기능이 지원됩니다.

가격: 무료
iReasoning Networks MIB Browser
iReasoning Networks MIB Browser

Greg Steen은 IT 전문가의 개발 및 관련 작업을 지원하기 위해 끊임없이 다양한 도구와 방법을 모색하는 기술 전문가입니다.


 SQL Q&amp;A: 메모리 구성, 성능 프로파일링, 채우기 비율 설정 및 기타 정보
SQL Q&A
메모리 구성, 성능 프로파일링, 채우기 비율 설정 및 기타 정보
편집자: Nancy Michell

메모리 구성
팁: 보다 쉬운 프로파일링
이제 SQL Server 2005 프로파일러와 PerfMon을 연결할 수 있습니다.
SQL Server 시스템의 성능 모니터에서 급격한 CPU 사용량 증가, 과도한 메모리 사용 또는 전체적인 성능 저하를 발견하고 이러한 성능 이상의 원인이 궁금한 적이 있을 것입니다. SQL Server 2005 이전 버전에서는 프로파일러를 사용하여 추적을 캡처한 다음 엔터프라이즈 관리자에서 sysprocess를 관찰하고 성능 모니터 로그를 캡처해야 했습니다. 물론 이렇게 하려면 PerfMon을 실행해야 했습니다. 이러한 도구를 모두 사용하여 작업한 뒤에도 이벤트를 도구 간에 수동으로 조정하여 성능 문제의 원인을 찾아야 했습니다. 즉, 모든 로그를 하나씩 검사해야 했습니다. 결코 재미있는 작업은 아니지만 성능 문제의 근본 원인을 밝히려면 이런 작업을 해야만 했습니다.
SQL Server 2005에서도 추적을 캡처하고 PerfMon 로그를 검사해야 하지만 이제는 프로파일러에서 이를 연결할 수 있습니다. T-SQL 문을 스크롤하면 어떤 작업이 수행되었는지 자동으로 표시됩니다. 프로파일러에서 성능 모니터 사용자 인터페이스를 클릭하면 해당 타임스탬프와 연결된 문으로 곧바로 이동할 수 있습니다. 이를 통해 SQL Server 환경의 문제 해결에 소요되는 시간이 크게 절약됩니다.
PerfMon 로그를 프로파일러에 연결하는 방법을 알아보겠습니다.
  1. 성능 모니터를 시작하고 데이터베이스 서버의 정보를 캡처합니다.
  2. 성능 로그 및 경고 아래에 새 카운터 로그를 만들고 새 로그의 이름을 입력합니다.
  3. % 프로세서 시간과 같은 새 카운터를 추가합니다. 로깅을 수동으로 시작하거나 일정 탭을 사용하여 일정에 따라 시작되도록 할 수 있습니다.
  4. 확인을 클릭하고 수동 옵션을 선택한 경우에는 로깅을 시작합니다.
  5. 프로파일러를 통해 SQL Server에 대한 추적을 설정합니다. 파일 메뉴에서 새 추적을 클릭하여 이를 수행할 수 있습니다. 추적에 StartTime 및 EndTime을 포함한 다음 추적의 이름을 지정하고 파일로 저장하도록 설정합니다. 마지막으로, 서버에서 일부 트랜잭션 활동을 시뮬레이션한 다음 성능 모니터와 프로파일러 데이터 캡처를 모두 중지합니다.
  6. 프로파일러의 파일 메뉴에서 성능 데이터 가져오기를 선택합니다. 그런 다음 PerfMon 로그를 저장한 위치를 선택하고 파일, 열기, 추적을 차례로 선택합니다. 마지막으로, 프로파일러 추적을 저장한 위치를 선택합니다.
이렇게 하면 특정 SQL 문이 처리 시간에 미치는 영향을 매우 쉽게 파악할 수 있습니다.

Q: SQL Server™ 시스템의 최적 메모리 구성을 알아보려고 합니다. 저의 전임 관리자는 SQL Server 2000 2노드 클러스터에서 12GB RAM이 장착된 각 시스템의 Boot.ini를 Yes /PAE NO /3GB(SQL Server에는 AWE를 설정하지 않음)로 설정했습니다. 12GB RAM을 사용할 수 있는 경우 Boot.ini의 /3GB 스위치를 제거하고, AWE를 설정하고, SQL Server에 12GB 중 10GB를 할당해야 할까요? 이 시스템에서는 SQL Server만 실행하므로 다른 응용 프로그램에는 메모리가 필요하지 않습니다.
A: 예. AWE(Address Windowing Extensions)를 설정하고 SQL Server에 대한 RAM의 상한을 미리 할당해야 합니다. 12GB의 전용 SQL Server 시스템이면 10GB가 적당한 듯합니다. 사전 할당은 SQL Server 2000에서만 유효함을 유의하십시오. SQL Server 2005부터는 AWE 사용이 더 이상 정적이 아니며 계속 변경될 수 있습니다. /3GB와 /PAE 스위치를 모두 사용할지 아니면 /PAE만 사용할지에 대해서는 항상 논란거리였습니다. /PAE를 설정하고 AWE를 사용할 수 있도록 설정하기만 하면 되지만 두 스위치 모두 사용할 것을 제안합니다. 하지만 몇 가지 고려해야 할 사항이 있습니다.
/3GB 스위치의 사용 여부는 사용자 특정 상황에 필요한지 여부에 따라 결정해야 합니다. 즉, 가상 주소 공간의 처음 2GB 또는 3GB에 있어야 하는 MemToLeave 메모리 영역이 부족한지 여부와 이 스위치를 설정하는 경우 운영 체제 메모리가 부족해지는지 여부를 고려해야 합니다. 자세한 내용은 support.microsoft.com/kb/316739를 참조하십시오. 클러스터에서 작업할 때는 하나의 노드에는 /3GB를 설정하고 다른 노드에는 설정하지 않는 방법도 있습니다. 이렇게 해서 /3GB를 사용하여 테스트했을 때 문제가 발생할 경우 인스턴스를 신속하게 다른 노드로 장애 조치할 수 있습니다. 16GB보다 큰 RAM이 있을 경우에는 /3GB 스위치가 지원되지 않음을 염두에 두어야 합니다.
/3GB를 사용하면 VAS(가상 주소 공간)가 50% 증가하므로 데이터 캐시뿐만 아니라 VAS에 사용할 메모리가 많이 부족한 응용 프로그램에 큰 이점이 있습니다. 다행히 64비트 서버 IA64 및 x64 모두에서는 이러한 오해의 소지가 없습니다. 시스템이 SQL Server 전용인 경우에는 OS 메모리 부족과 관련된 문제가 해당되지 않습니다. OS용으로 2GB를 할당하는 것도 다소 과합니다. 이 서버가 최소의 표준 OS 서비스만 실행하는 SQL Server 전용 시스템인 경우에는 서버에 약 1.3GB의 여유 메모리가 남는 것을 확인할 수 있으므로 SQL Server가 이 여분의 1GB를 사용하도록 할 수 있습니다. 10GB부터는 PerfMon을 사용하여 장시간에 걸쳐 가용 메모리를 모니터함으로써 얼마나 많이 유휴 상태에 놓이는지 확인하여 그에 따라 조정하십시오. AWE는 SQL Server 2005에서처럼 동적이지 않으므로 SQL Server 2000에서 오버 커밋하면 스와핑이 발생할 수 있음을 유의하십시오. /3GB 스위치 사용 여부를 결정하는 데 있어 중요한 점은 실제 환경에서 테스트해봐야 한다는 점입니다.

복제 인스턴스 이름
Q: 이제 서버의 IP 주소를 SQL Server 2005 복제에 사용하여 복제할 인스턴스를 지정할 수 있습니까? "트러스트되지 않은 도메인에서 또는 인터넷을 통해 실행되는 컴퓨터 간 복제"(support.microsoft.com/kb/321822)에 따르면 SQL Server 2000에서 이렇게 하면 오류가 발생한다고 하지만 이 경우에도 해당하는지 알고 싶습니다.
A: 서버 인스턴스가 복제에 참여하도록 지정할 때는 SQL Server에 등록된 인스턴스 이름을 제공해야 합니다. 예를 들어 Publisher 또는 Subscriber 매개 변수를 복제 저장 프로시저 또는 명령줄의 복제 에이전트 연결 설정에 지정할 때는 SQL Server 인스턴스 이름을 사용해야 합니다. SQL Server 인스턴스의 네트워크 이름이 등록된 인스턴스 이름과 다른 경우 에이전트에 의한 복제 연결이 실패합니다.
인스턴스의 네트워크 이름과 SQL Server 인스턴스 이름이 다른 경우에는 SQL Server 인스턴스 이름을 올바른 네트워크 이름으로 추가하는 방법을 고려하십시오. 대체 네트워크 이름을 설정하는 한 가지 방법은 로컬 호스트 파일에 이 이름을 추가하는 것입니다. 로컬 호스트 파일은 기본적으로 WINDOWS\system32\drivers\etc 또는 WINNT\system32\drivers\etc에 있습니다. 예를 들어 컴퓨터 이름이 comp1이고, 컴퓨터 IP 주소가 10.193.17.129이고, 인스턴스 이름이 inst1/instname이면 호스트 파일에 다음 항목을 추가합니다.
10.193.17.129 inst1

SQL Server Integration Services
Q: SQL Server 2005(두 개의 서버를 사용하는 64비트 Enterprise Edition)를 위한 액티브/액티브 클러스터를 설치하려고 하며 총 네 개의 SQL Server 2005 인스턴스를 사용하려고 합니다. 모든 인스턴스에 SSIS(SQL Server Integration Services)가 필요합니다. SSIS의 클러스터링에 대해 조언을 해주시고 유지 관리 계획에 어떤 영향을 미칠지 알려주십시오.
A: SSIS 서비스를 클러스터할 수는 있지만 반드시 그렇게 할 필요는 없습니다. 클러스터할 경우 위임이 지원되지 않고(msdn2.microsoft.com/aa337083 참조), 다중 인스턴스화되지 않는(한 번에 하나의 인스턴스만 노드에서 실행 가능) 등의 여러 문제가 발생할 수 있습니다.
이전에는 유지 관리 계획 마법사를 실행하려면 SSIS가 설치되어 있어야 했습니다(실행 중일 필요는 없고 설치만 되어 있으면 됨). 하지만 SQL Server 2005 SP1에서는 이러한 요구 사항이 없어졌습니다. SSIS가 실행되고 있지 않은 경우에는 SQL Server 에이전트에서 유지 관리 계획을 실행할 수 있습니다.
SSIS를 클러스터링하는 대신 독립 실행형 서비스로 실행되도록 하고 MsDtsSrvr.ini.xml을 편집하여 모든 실행 중인 인스턴스를 가리키도록 하는 방법을 고려할 수 있습니다. 이렇게 하면 모든 노드에서 패키지를 관리할 수 있으며 서비스 클러스터링과 관련된 문제 없이 대부분의 고객이 원하는 고가용성을 확보할 수 있습니다.
실패한 유지 관리 계획 작성에 대한 자세한 내용은 support.microsoft.com/kb/909036의 기술 자료 문서를 참조하십시오.

이상한 실행 시간
Q: SQL Server 2005 SP1 시스템에 대해 부하 테스트를 수행했더니 SQL Server 프로파일러가 여러 개의 음수 SP(저장 프로시저) 실행 값을 기록하고, SP 실행 시간이 종료 시간에서 시작 시간을 뺀 결과와 일치하지 않는 경우가 있었습니다.
A: SQL Server 프로파일러의 SP 실행 시간 및 기타 성능 시간 보고에 영향을 줄 수 있는 사항에는 여러 가지가 있습니다. SQL Server 2005에서는 실행 시간을 잴 때 밀리초를 사용하며, 측정 단위를 변경하는 기술을 사용하고 있으면 보고 및 실행 시간이 정확하지 않을 수 있습니다.
예를 들어 다른 전원 구성표, CPU 스테핑 또는 AMD Cool 'n Quiet 기술을 사용하면 CPU 주파수가 변경되어 SQL Server 프로파일러가 실행 시간을 계산할 때 예측한 값과 일치하지 않게 됩니다.
기술 자료 문서 support.microsoft.com/kb/931279에서 증상, 여러 원인 및 몇 가지 해결 방법을 볼 수 있습니다.
팁: 채우기 비율 확인
물을 가득 채운 유리컵이 있는데 이 컵에 물을 더 채우려고 한다고 가정해 보십시오. 어떻게 될까요? 물이 넘칠 것입니다.
SQL Server의 경우에도 마찬가지입니다. 가득 찬 인덱스 페이지에 새 행을 추가할 때마다 SQL Server는 새 행을 위한 공간을 마련하기 위해 전체 행의 약 절반을 새 페이지로 이동합니다. 이를 페이지 분할이라고 합니다. 페이지 분할을 통해 새 레코드를 위한 공간이 생기지만 시간이 소요되며 리소스가 많이 소비됩니다. 또한 I/O 작업에 부정적 영향을 줄 수 있는 조각화를 초래할 수 있습니다. 이 문제를 피하려면 어떻게 해야 할까요?
이러한 문제를 피하려면 채우기 비율 값을 사전에 확인해야 합니다. 인덱스를 만들거나 다시 작성할 때는 이 채우기 비율 값에 따라 각 리프 수준 페이지에서 데이터로 채워질 공간의 비율이 결정되고 나머지는 향후 확장에 대비하여 예약됩니다. 예를 들어 채우기 비율 값이 60이면 각 리프 수준 페이지의 40%는 기본 테이블에 데이터가 추가될 때 인덱스가 확장될 수 있도록 비어 있게 됩니다.
기본 채우기 비율 값은 항상 0이며 이는 대부분의 상황에 적합합니다. 기본적으로 채우기 비율 값 0은 리프 수준이 거의 용량 한계까지 채워지지만 최소 하나의 추가 인덱스 행을 위해 약간의 공간이 남겨진다는 의미입니다. 채우기 비율 값 0과 100은 비슷합니다.
CREATE INDEX 또는 ALTER INDEX 문에서 개별 인덱스에 대한 채우기 비율 값을 설정하거나 새로 작성되는 모든 인덱스가 기본값을 사용하도록 서버 수준에서 이 값을 직접 구성할 수 있습니다.
다음 예제에서는 서버 수준에서 채우기 비율 값을 70%로 설정하여 향후 확장에 대비하여 여유 공간을 30% 확보합니다. 물론 프로덕션 환경에서는 이 옵션을 구현하기 전에 신중하게 테스트해야 합니다.
USE Master; GO SP_Configure 'show advanced options',1; GO SP_Configure 'Fill Factor', 70; GO --변경 사항을 적용하려면 SQL Server Engine을 다시 시작해야 합니다.
참고: 프로그래머 주석은 예제 프로그램 파일에는 영문으로 제공되며 기사에는 이해를 돕기 위해 번역문으로 제공됩니다. 개별 인덱스 수준에서 채우기 비율을 구성하려면 어떻게 해야 할까요? 다음 테이블을 작성한 후 Col_A라는 열에 채우기 비율 값을 70으로 설정하여 고유한 인덱스를 만들려고 한다고 가정하겠습니다. 이 경우 명령은 다음과 같습니다.
--Item 테이블을 만듭니다. USE Item_DB; GO CREATE TABLE ITEM (Col_A Varchar(100),Col_b Varchar(200)); GO;

--Item 테이블의 Col_A 열에 채우기 비율 값을 70으로 설정하여 고유한 인덱스를 만듭니다. CREATE UNIQUE INDEX AK_Index ON Item (Col_A) WITH (FillFactor = 70); GO
각 인덱스에 대한 채우기 비율은 어떻게 확인할까요? 다음과 같이 sys.Indexes를 쿼리하면 데이터베이스의 모든 인덱스에 대한 채우기 비율 값을 확인할 수 있습니다.
USE Item_DB; GO SELECT Fill_Factor FROM Sys.Indexes WHERE Object_id=object_id('item') AND name IS NOT NULL; GO


 Utility Spotlight: Microsoft Security Assessment Tool
Utility Spotlight
Microsoft Security Assessment Tool
Lance Whitney
이 기사의 코드 다운로드: Microsoft Security Assessment Tool 3.0(영어 버전만 제공됨) (10547.2KB)

네트워크 보안 문제를 추적하는 작업은 복잡할 뿐만 아니라 시간도 많이 걸립니다. 이러한 보안 위험을 파악하고 해결하는 데 유용한 도구 중 하나가 바로 Microsoft® Security Assessment Tool(MSAT)입니다. 무료로 제공되는 이 유틸리티는 조직의 보안 환경을 설명하는 데 사용할 수 있는 전자 설문지를 제공합니다. 50~500대의 컴퓨터를 갖춘 중간 규모 조직에 맞게 설계된 MSAT는 범주별로 구성된 172가지의 질문을 통해 현재의 상황을 분석하여 이를 개선할 수 있는 권장 사항을 제시합니다.
MSAT는 사용자의 비즈니스 모델과 관련된 일련의 질문으로 시작하여 이를 기반으로 BRP(비즈니스 위험 프로필)를 만들고 이 BRP를 통해 사용자 조직의 보안 위험을 동종 업계의 다른 조직과 비교 평가합니다. 이 설문지를 작성하는 데는 대개 두 시간 정도 걸리며 언제든지 중단했다가 다시 시작할 수 있습니다. 다음은 질문의 범주 및 각 범주에 해당하는 질문의 예입니다.
기본 정보 조직에서 사용하는 클라이언트 및 서버의 수는 얼마나 됩니까?
인프라 보안 직원이 원격 위치에서 작업합니까? 외부의 계약 직원이 조직 네트워크에 액세스합니까?
응용 프로그램 보안 회사에서 응용 프로그램을 개발합니까? 응용 프로그램에서 처리하는 중요한 데이터를 이러한 응용 프로그램에 저장합니까?
운영 보안 회사 네트워크가 외부 네트워크에 연결됩니까? 조직에서 외부 조직으로부터 데이터 피드를 받습니까?
인적 보안 회사에서 컴퓨터 유지 관리 작업을 외부 용역으로 처리하고 있습니까? 직원이 회사의 중요한 데이터를 자신의 워크스테이션으로 다운로드하는 것이 허용됩니까?
환경 조직의 직원 수는 얼마나 됩니까? IT 부서의 직원 교체 속도가 빠릅니까?
설문을 마치면 MSAT는 조직에서 현재 사용하는 보안 프로세스에 중점을 둔 DiDI(심층 방어 지표)라는 측정 방법을 통해 평가를 진행합니다. 이때도 앞에서와 비슷한 범주를 사용하며 제시되는 질문은 '조직의 각 위치에서 방화벽을 사용하고 있습니까?', 'Microsoft Office 응용 프로그램에서 사용자 지정 매크로를 사용합니까?', '사용자가 자신의 워크스테이션에 대한 관리 권한을 가지고 있습니까?', '패치 및 업데이트를 PC에 배포하기 위한 정책이 있습니까?' 등입니다.
사용자의 답변에 기초하여 MSAT는 세 가지 보고서를 제공합니다. Summary Report(요약 보고서)에서는 결과를 막대 그래프로 표시합니다. 높은 BRP 값은 높은 위험 수준을 나타내는 반면 높은 DiDI 값은 우수한 보안을 나타냅니다. BRP가 낮고 DiDI가 높으면 현재의 보안이 양호한 것처럼 보일 수도 있습니다. 하지만 MSAT에서 지적하듯이 이 수치보다 중요한 것은 개별 영역을 검토하는 것입니다. Complete Report(전체 보고서)에서는 각 영역별로 사용자 조직에서 최선의 방법을 따르고 있는지, 개선이 필요한지, 위험에 대한 대비가 많이 부족한지를 보여 줍니다(그림 1참조).
그림 1 Complete Report(전체 보고서)
그림 1 Complete Report(전체 보고서)
마지막으로 Comparison Report(비교 보고서)에서는 사용자 조직에 대해 생성된 결과를 다른 조직의 결과와 비교할 수 있도록 안전한 MSAT 웹 사이트에 결과를 익명으로 업로드하도록 요청합니다.
MSAT는 Microsoft Security Guidance 웹 사이트(<A href="http://securityguidance.com">securityguidance.com</A>)나 <I>TechNet Magazine</I> 웹 사이트(<A href="http://technetmagazine.com/code07.aspx">technetmagazine.com/code07.aspx</A>)에서 다운로드할 수 있습니다.

Lance Whitney는 IT 컨설턴트 겸 강사이자 테크니컬 라이터로, Windows 워크스테이션과 서버를 조정하는 데 많은 시간을 할애하고 있습니다. 원래 저널리스트였던 그는 15년 전 IT 업계에 뛰어들었습니다.


 The Cable Guy: 네트워크 정책 서버
The Cable Guy
네트워크 정책 서버
Joseph Davies
이 칼럼은 Windows Server 2008의 시험판 버전을 기준으로 작성되었습니다. 이 문서에 수록된 모든 정보는 변경될 수 있습니다.

Windows Server 2008의 NPS(네트워크 정책 서버) 서비스는 Windows Server 2003의 IAS(인터넷 인증 서비스)를 대체합니다. NPS를 사용하면 Windows Server 2008을 실행하는 컴퓨터를 RADIUS(Remote Authentication Dial-In User Service) 서버 및 프록시로 활용할 수 있습니다. RADIUS는 RFC 2865 및 2866에 명시된 IETF(Internet Engineering Task Force) 프로토콜이며 무선 액세스 지점과 같은 네트워크 액세스 장치에 대한 AAA(인증, 권한 부여, 계정 구성) 작업을 한곳에서 모두 처리할 수 있게 해 줍니다. RADIUS 서버는 네트워크 액세스 장치를 대상으로 AAA 작업을 수행합니다.
RADIUS 프록시는 RADIUS 클라이언트(네트워크 액세스 장치)와 RADIUS 서버 사이에서 RADIUS 메시지를 전달합니다.
NPS는 인증된 네트워크 액세스의 배포를 용이하게 하고 타사 구성 요소에 대한 확장성을 제공하며 최신 네트워킹 기술과 플랫폼을 지원하는 등 수많은 사항이 개선되었습니다. 그림 1에서는 새로운 NPS 스냅인을 보여 줍니다.
그림 1 새로운 NPS 스냅인
그림 1 새로운 NPS 스냅인

네트워크 정책 서버의 기능
이번 칼럼에서는 이전 버전의 Windows®에는 없는 NPS 기능에 대해 소개합니다. 우선 NAP(네트워크 액세스 보호)가 네트워크에 대한 상태 요구 사항을 적용하는 데 어떻게 도움이 되는지 살펴본 후 관리, 구성, IPv6 지원 및 기타 요소들을 설명하겠습니다. 새로운 NPS 스냅인의 기능도 설명하겠습니다.
네트워크 액세스 보호 Windows Server® 2008에 도입된 NAP는 컴퓨터의 상태 요구 사항을 충족하도록 하여 인트라넷을 더욱 효과적으로 보호할 수 있게 해 주는 일련의 새로운 기술입니다. 예를 들어 상태 정책을 사용하면 방화벽을 반드시 설치하여 실행할 것, 네트워크에 연결된 모든 클라이언트에 반드시 최신 운영 체제 업데이트를 설치할 것 등의 요구 사항을 지정할 수 있습니다. NAP를 사용하면 네트워크 액세스 또는 통신을 허용하기 전에 컴퓨터의 상태를 인증하고, 현재 적용되는 규정을 준수하도록 컴퓨터를 자동으로 업데이트하고, 규정을 준수하지 않는 컴퓨터는 규정을 준수할 때까지 제한된 네트워크를 벗어나지 못하게 하는 등의 사용자 지정 정책을 만들 수 있습니다. 자세한 내용은 microsoft.com/nap를 참고하십시오.
NAP 배포 환경에서 NPS 서버는 HRA(상태 등록 기관), 802.1X 액세스 지점, VPN(가상 사설망) 서버, DHCP(동적 호스트 구성 프로토콜) 서버 등 NAP 적용 지점을 대신하여 NAP 클라이언트의 상태를 평가하는 NAP 상태 정책 서버입니다. NPS 서버는 또한 클라이언트에 인트라넷에 대한 모든 액세스를 허용할 것인지 또는 제한적인 액세스를 허용할 것인지도 결정합니다. 네트워크 정책, 상태 정책 및 NAP 설정에 따라 NPS의 상태 평가 동작이 결정됩니다.
EAPHost와 EAP 정책 지원 NPS는 EAP(확장할 수 있는 인증 프로토콜) 인증 방법을 위한 새로운 아키텍처인 EAPHost를 지원합니다. 이 새로운 아키텍처에서는 EAP 방법 공급업체가 클라이언트 컴퓨터와 NPS 서버 모두를 대상으로 802.1X 또는 PPP(지점 간 프로토콜) 기반 인증을 위한 새로운 EAP 방법을 쉽게 개발하여 설치할 수 있습니다.
EAPHost는 EAP 레지스트리(www.iana.org/assignments/eap-numbers)에 수록된 모든 EAP 방법의 설치 및 사용뿐만 아니라 Cisco Systems의 LEAP(Lightweight EAP)와 같이 널리 사용되는 다른 인증 방법도 지원합니다. EAPHost에서는 EAP 방법을 다양한 방식으로 구현할 수 있습니다. 예를 들어 PEAP(보호된 EAP)의 Microsoft 버전과 Cisco Systems 버전을 모두 설치하고 선택할 수 있습니다.
EAP 방법 공급업체의 경우 EAPHost는 Windows XP 및 Windows Server 2003용으로 이미 개발된 EAP 방법을 지원할 뿐만 아니라 Windows Vista® 및 Windows Server 2008용의 새로운 EAP 방법을 더욱 쉽게 개발할 수 있게 해 줍니다. 설치한 후에는 특정한 네트워크 액세스 시나리오에 필요한 EAP 방법을 네트워크 정책에 구성할 수 있습니다. NPS에 대한 네트워크 정책은 IAS에 대한 원격 액세스 정책과 동일합니다.
EAPHost 아키텍처에 대한 자세한 내용은 technetmagazine.com/issues/2007/05/CableGuy를 참고하십시오.
XML로 구성 저장 IAS에서는 구성 정보가 Jet 데이터베이스에 저장됩니다. NPS에서는 구성 정보가 XML 형식으로 저장되므로 더욱 간편하게 특정 NPS 서버의 구성 정보를 내보내서 다른 NPS 서버로 가져올 수 있습니다. 구성 파일 내보내기 및 가져오기는 내결함성 구성에서 여러 NPS 서버의 설정을 동기화할 수 있는 한 가지 방법입니다. NPS 구성을 내보내는 명령은 netsh nps export이며 가져오는 명령은 netsh nps import입니다.
공통 엔지니어링 기준 준수 NPS는 Microsoft® CEC(공통 엔지니어링 기준)를 충족해야 하는 환경에서의 배포를 지원하도록 업데이트되었습니다. 자세한 내용은 microsoft.com/windowsserversystem/cer/allcriteria.mspx를 참고하십시오.
강력한 NPS 확장 DLL NPS 서비스는 확장 및 권한 부여 DLL을 통해 확장할 수 있습니다. IAS와는 달리 NPS에서는 이러한 타사 구성 요소들이 안전하게 격리되기 때문에 문제가 발생하더라도 NPS 서비스의 작동 또는 실행은 영향을 받지 않습니다.
IPv6 지원 NPS는 IPv6뿐만 아니라 네이티브 또는 터널링된 IPv6 환경에서의 배포도 지원합니다. RADIUS 클라이언트 또는 원격 RADIUS 서버의 IPv6 주소를 구성할 수 있으며 NPS 서비스는 IPv6을 통해 통신을 수행하여 Active Directory® 도메인 서비스 계정 인증 및 권한 부여 작업을 수행할 수 있습니다.
IAS와 NPS 비교
NPS 스냅인에는 Windows Server 2003용 IAS 스냅인에 익숙한 사용자가 환영할 만한 다음과 같은 변화가 있습니다.
  • 원격 액세스 정책은 네트워크 정책이 되어 정책 노드로 옮겨졌습니다.
  • RADIUS 클라이언트 노드는 RADIUS 클라이언트 및 서버 노드로 옮겨졌습니다.
  • 연결 요청 처리 노드는 이제 존재하지 않습니다. 연결 요청 정책 노드는 정책 노드로 옮겨졌으며 원격 RADIUS 서버 그룹 노드는 RADIUS 클라이언트 및 서버 노드로 옮겨졌습니다.
  • 원격 액세스 정책 조건 및 프로필 설정은 네트워크 정책 속성에 대한 개요, 조건, 제약 조건 및 설정 탭에서 재구성되었습니다.
  • 연결 요청 정책 조건 및 프로필 설정은 연결 요청 정책 속성에 대한 개요, 조건 및 설정 탭에서 재구성되었습니다.
  • 원격 액세스 로깅 폴더는 계정 노드로 이름이 바뀌었으며 로컬 파일 또는 SQL ServerTM 노드를 더 이상 포함하지 않습니다.

강력한 RADIUS 공유 암호 자동 생성 RADIUS 공유 암호는 RADIUS 메시지가 동일한 공유 암호로 구성된 RADIUS 클라이언트, 서버 또는 프록시로부터 전송되었는지 확인하는 데 사용됩니다. 또한 공유 암호는 암호 및 암호화 키 등 몇 가지 중요한 RADIUS 특성을 암호화하는 데에도 사용됩니다. 강력한 RADIUS 공유 암호는 임의의 문자, 숫자 및 문장 부호가 길게(23자 이상) 나열된 형태를 갖습니다.
NPS 스냅인을 사용하면 RADIUS 클라이언트를 추가 또는 편집할 때 강력한 RADIUS 공유 암호를 자동으로 생성할 수 있습니다. 이러한 강력한 공유 암호는 메모장 등의 텍스트 편집기에 복사할 수 있으므로 네트워크 액세스 장치 또는 NAP 적용 지점을 동일한 암호로 구성할 수 있습니다.
서버 관리자와의 통합 NPS는 초기 구성 작업 도구 및 서버 관리자 도구를 사용하여 설치할 수 있습니다. 두 경우 모두 네트워크 정책 및 액세스 서비스 역할과 함께 NPS를 설치합니다. 우선 초기 구성 작업 도구의 이 서버 사용자 지정에서 역할 추가 옵션을 클릭합니다. 서버 관리자 도구에서는 역할 요약을 열고 역할 추가를 클릭합니다.
NPS를 설치한 경우 서버 관리자의 콘솔 트리에서 역할 노드 아래에 있는 네트워크 정책 및 액세스 서비스를 클릭하여 NPS 서비스의 상태를 확인하고 지난 24시간 동안 발생한 오류 이벤트를 조회할 수 있습니다. 이 콘솔에서 네트워크 정책 및 액세스 서비스 노드를 확장하면 NPS 스냅인으로 NPS를 구성할 수 있습니다.
향상된 Netsh 지원 Windows Server 2003에서는 IAS를 구성하기 위한 netsh aaaa 컨텍스트의 명령이 한정되어 있었습니다. Windows Server 2008의 새로운 netsh nps 컨텍스트에서는 명령줄 또는 스크립트를 통해 NPS를 구성할 수 있는 명령이 더 많아졌습니다. 이제 netsh nps 명령을 사용하면 RADIUS 클라이언트와 원격 RADIUS 서버, 네트워크 정책, 로깅, NAP, 상태 정책, 시스템 상태 검사기, 업데이트 관리 서버 그룹 등을 구성할 수 있습니다. netsh nps 컨텍스트의 명령으로 스크립트를 구성하여 내결함성 구성에서 여러 NPS 서버의 설정을 동기화할 수 있는 방법으로 사용할 수 있습니다.
네트워크 정책 격리를 위한 소스 태그 네트워크 정책은 특정 유형의 네트워크 액세스 서버 또는 네트워크 정책을 분류하는 소스 태그가 되는 DHCP 서버, HRA 등의 NAP 적용 지점을 대상으로 구성될 수 있습니다. Windows Server 2008 기반의 액세스 서버와 NAP 적용 지점은 자신의 RADIUS 메시지에 이 소스 태그를 포함합니다. 액세스를 요청하는 RADIUS 메시지가 수신되면 NPS 서비스는 들어오는 메시지와 동일한 소스 태그가 있는 네트워크 정책을 찾습니다. 일치하는 정책이 없을 경우 NPS는 지정된 소스 태그가 없는 정책에 맞는 네트워크 정책을 찾게 됩니다.
네트워크 정책과 들어오는 RADIUS 메시지의 소스 태그를 사용하면 각기 다른 유형의 네트워크 정책들을 서로 격리할 수 있습니다. 예를 들어 DHCP 서버에 대한 네트워크 정책이 VPN 연결에 사용되지 않도록 할 수 있습니다.
Cisco Network Access Control과의 통합 NPS는 Cisco 하드웨어와 NAC(Network Access Control)를 사용하는 환경에 더욱 효과적으로 통합되는 기능을 지원합니다. 이러한 기능으로는 HCAP(호스트 자격 인증 프로토콜) 및 HCAP 조건 지원, 정책 만료 조건 지원, 네트워크 정책의 확장된 상태 네트워크 액세스 보호 설정에 대한 지원 등이 있습니다.
새로운 네트워크 정책 조건 NPS의 네트워크 정책에는 컴퓨터 그룹, 사용자 그룹, 허용된 EAP 유형, 클라이언트 및 액세스 서버 IPv6 주소 등을 지정하기 위한 새로운 조건이 있습니다. NPS에는 HCAP 지원을 위해 위치 그룹 및 사용자 그룹에 대한 새로운 조건이 있으며, NAP 지원을 위해서는 ID 유형, 상태 정책, NAP 지원 컴퓨터, 운영 체제, 정책 만료 등을 위한 새로운 정책 조건이 추가되었습니다.
NPS 스냅인 새로운 NPS 스냅인은 RADIUS 클라이언트와 원격 RADIUS 서버, 공통 네트워크 액세스 시나리오를 위한 네트워크 정책, NAP 시나리오를 위한 NAP 설정과 상태 정책, 로깅 설정 등을 더욱 쉽게 만들어 관리할 수 있도록 대폭 향상되었습니다.
RADIUS 클라이언트 및 서버 노드에서는 RADIUS 클라이언트(NPS가 RADIUS 서버로 작동할 경우에는 네트워크 액세스 서버, NAP 적용 지점 또는 기타 RADIUS 프록시)와 원격 RADIUS 서버 그룹(NPS가 RADIUS 프록시로 작동할 경우에는 다른 RADIUS 서버)을 구성할 수 있습니다.
정책 노드에서는 연결 요청 정책(NPS 서비스가 RADIUS 서버로 또는 프록시로 작동할 것인지 여부), 네트워크 정책(NPS 서비스가 RADIUS 서버로 작동할 경우 권한 부여 및 연결 설정과 제약 조건) 및 상태 정책(NAP 클라이언트를 위한 시스템 상태 규정 준수)을 구성할 수 있습니다. 세부 정보 창에서 연결 요청 정책 또는 네트워크 정책을 선택하면 NPS 스냅인에 정책의 조건과 설정이 표시됩니다. 그림 2에서 예제를 확인할 수 있습니다.
그림 2 향상된 NPS 스냅인 표시 내용
그림 2 향상된 NPS 스냅인 표시 내용
네트워크 액세스 보호 노드의 시스템 상태 검사기 노드에서 NAP 상태 요구 사항을 구성할 수 있습니다. 업데이트 관리 서버 그룹 노드에서는 제한된 NAP 클라이언트가 VPN 및 DHCP NAP 적용 방법에 대해 액세스할 수 있는 서버 집합을 구성할 수 있습니다. 마지막으로 계정 노드에서는 NPS가 계정 정보를 저장하는 방법을 구성할 수 있습니다.
NPS 스냅인에는 NAP 적용 방법, 전화 접속 또는 VPN 기반 연결 및 802.1X 인증 유무선 연결에 필요한 정책과 RADIUS 클라이언트의 초기 구성 작업을 자동화하는 다양한 마법사가 포함되어 있습니다. NAP 적용 방법의 경우 NAP 마법사는 모든 연결 요청 정책, 네트워크 정책 및 상태 정책을 자동으로 구성합니다.
NPS 스냅인에서 NPS 노드를 클릭하면 이 새로운 마법사들을 사용할 수 있습니다. NAP 적용 방법에 대한 정책과 설정을 구성하려면 표준 구성 드롭다운 상자에서 네트워크 액세스 보호를 선택하고 NAP 구성을 클릭합니다. VPN 또는 전화 접속 네트워크 액세스에 대한 정책과 설정을 구성하려면 표준 구성 드롭다운 상자에서 전화 접속 또는 VPN 연결을 위한 RADIUS 서버를 선택하고 VPN 또는 전화 접속 구성을 클릭합니다. 802.1X 인증 유무선 액세스에 대한 정책과 설정을 구성하려면 표준 구성 드롭다운 상자에서 802.1X 무선 또는 유선 연결을 위한 RADIUS 서버를 선택하고 802.1X 구성을 클릭합니다.
각 마법사는 선택된 시나리오에 가장 일반적인 구성 요소에 대해 안내합니다. 그 중에서 NAP 적용 방법에 대한 마법사가 특히 유용합니다. VPN 적용에 대한 NAP 마법사를 통해 1개의 연결 요청 정책, 3개의 네트워크 정책(규정을 준수하는 NAP 클라이언트, 규정을 준수하지 않는 NAP 클라이언트 및 NAP를 지원하지 않는 클라이언트용) 및 2개의 상태 정책(규정을 준수하는 NAP 클라이언트와 규정을 준수하지 않는 NAP 클라이언트용)을 만들 수 있습니다.
이와 같은 새로운 NAP 마법사와 RADIUS 클라이언트, 원격 RADIUS 서버 그룹, 연결 요청 정책 및 네트워크 정책을 만들기 위한 기타 마법사를 사용하면 다양한 네트워크 액세스 시나리오에 맞게 NPS를 구성하는 작업을 훨씬 더 간편하게 수행할 수 있습니다.

Joseph Davies Microsoft의 기술 전문 저술가로 1992년부터 Windows 네트워킹을 주제로 글을 쓰고 가르치는 일을 하고 있습니다. Microsoft Press에서 5권의 책을 저술한 그는 월간 온라인 TechNet Cable Guy 칼럼의 저자이기도 합니다.


 Windows PowerShell: 자세히 알아보기
Windows PowerShell
자세히 알아보기
Don Jones

Windows PowerShell에는 많은 관리자가 무심코 보아 넘기기 쉬운 많은 기능이 있으므로 자세히 알아보면 놀라운 기능을 찾을 수 있습니다. 사실 Windows PowerShell의 모든 기능을 샅샅이 알고 있다고 생각하던 필자도 특정 cmdlet과 관련된 새로운 기능을 찾아낼 때가 많이 있습니다.
필자가 진행하는 Windows PowerShellTM 강의에서 필자는 시중에서 판매되는 '오늘의 한마디' 달력과 비슷한 '오늘의 cmdlet' 달력을 스스로 만들어 볼 것을 관리자들에게 권합니다. 그리고 매일 아침에(주말은 제외) 몇 분씩만 투자하면 cmdlet의 모든 기능을 익힐 수 있을 것입니다. Windows PowerShell에는 약 130개의 cmdlet이 있으므로 이 일정을 잘 지키기만 하면 6개월 안에 Windows PowerShell의 모든 기능을 익힐 수 있습니다. 그러면 모든 Exchange Server 2007 cmdlet을 사용할 준비가 될 것입니다.
이번 달의 칼럼에서는 몇 분을 투자해 다양한 cmdlet의 기능을 자세히 살펴봄으로써 얻을 수 있는 것과 발견할 수 있는 것을 몇 가지 예를 들어 소개해 보겠습니다.

보기 좋은 HTML 보고서
제대로 활용되지 않고 있는 cmdlet 중 하나가 ConvertTo-HTML입니다. 이 cmdlet은 서비스, 프로세스, WMI(Windows® Management Instrumentation) 개체 등의 입력 개체 컬렉션을 받아서 HTML 표로 바꿀 수 있습니다. 그런 다음 HTML을 Out-File로 파이핑하여 인트라넷 웹 서버에 게시하기에 적합한 HTML 페이지를 생성할 수 있습니다. 예를 들어 매일 아침 다음과 같은 간단한 줄을 실행하도록 예약할 수 있습니다.
Gwmi Win32_Service | Where { $_.StartMode –eq "Auto" –and $_.State –ne "Running" } | ConvertTo-HTML | Out-File C:\ServiceAlert.html
그러면 그림 1과 같이 자동으로 시작되어야 하지만 실행되고 있지 않은 서비스에 대한 HTML 보고서를 만들 수 있습니다.
그림 1 실행되고 있지 않은 서비스에 대한 HTML 보고서
그림 1 실행되고 있지 않은 서비스에 대한 HTML 보고서
물론 더 보기 좋은 보고서를 만들고 싶을 것입니다. 다행스럽게 ConvertTo-HTML cmdlet은 깔끔한 HTML을 생성합니다. 즉, 이 cmdlet에서 생성되는 HTML 코드에는 서식이 포함되지 않습니다. HTML 규칙에 따르면 HTML에 서식을 넣지 않아야 하며 부득이 넣어야 하는 경우에도 최소한으로 넣어야 합니다. 대신 서식은 외부 CSS(Cascading Style Sheet)에 넣고 이 CSS를 HTML에 연결해야 합니다. ConvertTo-HTML을 사용하면 이러한 연결을 만들 수 있습니다.
CSS는 HTML 파일의 <HEAD> 섹션에 연결됩니다. ConvertTo-HTML의 도움말을 보면 간과하기 쉬운 매개 변수가 구문에 들어 있음을 알 수 있습니다.
ConvertTo-Html [[-property] <Object[]>] [-inputObject <psobject>] [-body <string[]>] [-head <string[]>] [-title <string>] [<CommonParameters>]
–head 매개 변수를 사용하면 스크립트의 <HEAD> 섹션에 넣을 HTML 코드를 추가로 지정할 수 있습니다. 이제 한 줄 코드를 수정하여 HTML 표에 적용할 서식이 들어 있는 기존 CSS 파일에 손쉽게 연결할 수 있습니다.
Gwmi Win32_Service | Where { $_.StartMode –eq "Auto" –and $_.State –ne "Running" } | ConvertTo-HTML -title "Services" -head "<link rel='stylesheet' href='styles.css' type='text/ css' />" | Out-File C:\ServiceAlert.html
여기서는 –head 매개 변수를 사용하여 출력 HTML 파일과 같은 폴더에 있는 CSS 파일에 대한 링크를 삽입했습니다. 또한 –title 매개 변수를 사용하여 웹 페이지의 제목을 설정했습니다. 그 결과는 그림 2에서 볼 수 있습니다. 필자가 사용한 Style.CSS 파일의 텍스트는 다음과 같습니다.
그림 2 CSS 파일을 사용하여 서식이 지정된 HTML 보고서
그림 2 CSS 파일을 사용하여 서식이 지정된 HTML 보고서
body { background-color:#EEEEEE; } body,table,td,th { font-family:Tahoma; color:Black; Font-Size:10pt } th { font-weight:bold; background-color:#CCCCCC; } td { background-color:white; }

더 쉬운 필터링
이달의 Cmdlet
이번 달에는 cmdlet 쌍인 Start-Transcript와 Stop-Transcript를 살펴보겠습니다. 두 cmdlet은 모두 Windows PowerShell 기록 로깅 기능, 즉 콘솔 창에 표시되는 모든 것을 지정된 텍스트 파일에 기록하는 기능을 제어하는 데 사용됩니다. 사용법은 매우 간단합니다. Start-Transcript를 실행하고 파일 이름을 지정합니다. 그런 다음 Stop-Transcript를 실행하여 기록을 종료하고 파일을 닫습니다. 이는 임시 셸 사용에서 정식 스크립트로 전환할 수 있는 좋은 방법입니다. 각 명령줄이 셸에서 정상 작동하면 미리 만든 기록 파일에서 이를 복사하고 붙여 넣기만 하면 됩니다. 물론 기록을 편집하여 실제 스크립트를 만들 수도 있습니다. 동료 MVP인 Jeffery Hicks의 경우에는 기록을 구문 분석하여 이를 Windows PowerShell PS1 파일로 만드는 스크립트를 작성하기도 했습니다. 이 스크립트는 blog.sapien.com/current/2006/11/28/powershell-transcripts.html에서 볼 수 있습니다.

이제 Get-WMIObject cmdlet을 살펴보겠습니다. Windows PowerShell 기본 제공 도움말에서 나열되는 구문을 보면 잘 활용되지 않는 몇 가지 기능을 발견할 수 있습니다.
Get-WmiObject [-class] <string> [[-property] <string[]>] [-namespace <string>] [-computerName <string[]>] [-filter <string>] [-credential <PSCredential>] [<CommonParameters>]
Windows PowerShell 초보자가 자주 하는 실수 중 하나는 다음과 같은 WMI 명령을 실행하는 것입니다.
Gwmi Win32_NTLogEvent –comp Server2
이 명령은 Server2에서 이벤트 로그 항목(모든 이벤트 로그 항목)을 검색합니다. 이 작업은 Server2가 처리하고 전송하는 데 약간의 시간이 걸리며, 이렇게 큰 컬렉션으로 유용한 작업을 하려면 Windows PowerShell에도 어느 정도의 시간이 필요합니다.
더 좋은 방법은 원하는 이벤트를 Server2가 찾아서 전송하도록 하는 것입니다. WQL(WMI Query Language) 쿼리를 사용하면 이렇게 할 수 있습니다. 쿼리 구문이 까다롭다고 생각하는 사람들도 있지만 Windows PowerShell에서는 –filter 매개 변수를 사용하여 WQL 쿼리의 필터링 부분만 지정하면 됩니다.
Gwmi Win32_NTLogEvent –comp Server2 –filter "EventIdentifier=1024"
이렇게 하면 모든 로그에서 이벤트 ID가 1024인 이벤트를 모두 검색합니다. 필터 조건에서 Windows PowerShell –eq 연산자가 아니라 =를 비교 연산자로 사용한다는 점에 유의하십시오. 필터가 조금 전에 처리를 위해 원격 컴퓨터의 WMI 서비스에 전달되었기 때문에 조건에 Windows PowerShell 구문이 아니라 WMI 구문을 사용해야 합니다.
이것은 실제로 Get-ChildItem과 같은 다른 cmdlet, Dir 및 Ls와 같은 별칭 뒤의 cmdlet에서 사용되는 -filter 매개 변수입니다. 대개의 경우 –filter 매개 변수는 필터 조건을 기반 기술에 직접 전달하기 때문에 소스 필터링이라고 하는 과정이 수행됩니다. 이 과정은 모든 개체를 가져와 Where-Object cmdlet을 통해 실행하여 원하지 않는 것을 필터링하는 것보다 대체로 빠릅니다.

무심코 지나친 Cmdlet
이렇게 하루에 하나씩 cmdlet을 배우는 방법은 이미 알고 있다고 생각한 cmdlet을 좀 더 깊이 있게 이해하는 데 도움이 됩니다. 하지만 하루에 한 cmdlet을 공부해야 하는 다른 이유는 못 보고 지나치기 쉬운 cmdlet을 전체적으로 찾아볼 수 있기 때문입니다. 많은 사람들이 사용하지는 않지만 필자가 즐겨 사용하는 것 중 하나가 Resolve-Path입니다. 와일드카드 경로를 지정하면 이 cmdlet은 경로가 일치하는 파일 및 폴더 이름의 컬렉션을 반환합니다. Get-ChildItem cmdlet(즉, 익숙한 Dir 또는 Ls 별칭)과 비슷하지만 전체 파일과 폴더 개체를 반환하는 것이 아니라 추가적인 필터링이나 처리를 위해 다른 cmdlet에 파이핑할 수 있는 간단한 문자열을 반환합니다. 사용법은 어렵지 않습니다.
Resolve-Path C:\P*
이 간단한 줄을 사용하면 C:\Program Files, C:\Processes.txt 등과 같은 경로가 반환됩니다. 그림 3에서 이 cmdlet을 사용하는 두 가지 예제를 보여 줍니다.
그림 3 무심코 지나치기 쉽지만, 유용한 Resolve-Path cmdlet의 사용
그림 3 무심코 지나치기 쉽지만, 유용한 Resolve-Path cmdlet의 사용

가장 기본적인 것부터 시작하기
cmdlet을 하루에 한 개씩 공부할 준비가 되었으면 Get-Command에 대한 별칭인 Gcm을 실행해 보십시오. 그러면 Exchange Server 2007 Management Shell, PowerShell Community Extensions 등 스냅인을 통해 추가한 것을 포함하여 Windows PowerShell에서 인식하는 모든 cmdlet의 목록을 볼 수 있습니다. 목록에서 첫 번째 항목(필자의 경우에는 Add-Content)을 선택하여 도움말을 읽어 보십시오.
Help Add-Content –full
각 매개 변수의 역할, cmdlet의 사용 예에 대한 완전한 설명을 보고 다른 상세한 정보를 찾으려면 간단한 기본 도움말 대신 전체 도움말을 보면 됩니다. 1-2분 투자하여 cmdlet을 실행해 보십시오. 프로덕션 환경에 영향이 없도록 가상 시스템에서 실행하십시오. 매일 같은 시간에 10분씩 투자하며, 이것을 습관으로 만드는 것이 좋습니다. 그러면 얼마 지나지 않아 Windows PowerShell이 제공하는 모든 기능을 자세히 이해할 수 있게 될 것입니다.

Don Jones는 SAPIEN Technologies의 수석 스크립팅 전문가이자 Windows PowerShell: TFM(SAPIEN Press, 2007)의 공동 저자입니다. 문의 사항이 있으시면 www.ScriptingAnswers.com으로 연락하십시오.


 Hey, Scripting Guy!: WinRM의 귀환
Hey, Scripting Guy!
WinRM의 귀환
The Microsoft Scripting Guys

Scripting Guy가 WinRM(Windows® Remote Management)에 대한 2부작 연재물을 구상하고 있을 때 한 가지 중요한 문제가 머리를 스치고 지나갔습니다. 바로 보안이었지요. Scripting Guy는 해리포터 시리즈의 완결편이 출시되는 과정에서, 예약 주문된 책이 실수로 공식 출간 날짜보다 먼저 배송돼 버린 문제를 익히 잘 알고 있습니다. 이게 문제가 되었을까요? 물론 아닙니다. 출판사에서는 사람들에게 출시 날짜 전까지는 책을 읽지 말아 달라고 요청했을 뿐입니다.
이건 시작에 불과했습니다. 책이 출간되기도 전에 책 내용은 물론 완결편의 결말이 누출되어 버린 겁니다. (책을 아직 읽지 않으셨다면 제가 내용을 알려 드리죠. 사실 해리포터의 정체는 무슨 마법사인지 뭔지 랍니다!) 이와 마찬가지로 책의 모든 내용을 스캔한 복사본이 곧바로 인터넷에 공개되기도 했고, 어떤 경우에는 저자인 J. K. Rowling이 책을 써내기도 전에 그 내용이 유포되곤 했습니다. 이런 모든 현상은 결국 보안의 누수로 인한 것이며 Scripting Guy는 이런 일이 일어나지 않도록 해야겠다고 결심했습니다 우리 Scripting Guy가 쓴 WinRM 2부작의 결말을 알아내기란 해리포터 시리즈의 결말을 유포하기로 작정하고 그 내용을 알아내는 것만큼이나 어려운 일이랍니다.
다행히 Scripting Guy는 비밀을 지킬 수 있었습니다. 사실 그 이유는 기사 마감 시한이 훨씬 지난 뒤에도 이 시리즈의 두 번째 원고를 작성하지 않았기 때문이었습니다. 하지만 이 칼럼을 쓰는 Scripting Guy는 8월에 휴가를 보내고 있었고 여러 Microsoft 직원들과 달리 그는 휴가 동안 컴퓨터를 쳐다보지도 않았습니다.
사실 휴가가 아닐 때도 컴퓨터를 잘 들여다보지 않지만 그건 별개의 문제에요.
하여간 저희는 독자 여러분이 지난 4주 동안 대하 소설 WinRM이 어떻게 끝날지 걱정하고 또 궁금해 하면서 밤잠을 설치셨다는 걸 잘 압니다. 다행히 이런 지루한 기다림에 종지부를 찍을 수 있게 되었습니다. 이제 Scripting Guy가 기획한 WinRM 2부작의 흥미로운 결말을 최초로 공개합니다. 사실 그 내용은 그림 1에 나와 있습니다.
Figure 1 결과 (Close Figure 1)
strComputer = "atl-fs-01.fabrikam.com"

Set objWRM = CreateObject("WSMan.Automation") Set objSession = objWRM.CreateSession("http://" & strComputer)

strDialect = "http://schemas.microsoft.com/wbem/wsman/1/WQL" strResource = "http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/*" strFilter = "Select Name, DisplayName From Win32_Service Where State = 'Running'"

Set objResponse = objSession.Enumerate(strResource, strFilter, strDialect)

Do Until objResponse.AtEndOfStream strXML = objResponse.ReadItem

    Set objXMLDoc = CreateObject("Microsoft.XMLDom") objXMLDoc.async=False objXMLDoc.loadXML(strXML)

    Set objElement = objXMLDoc.documentElement Wscript.Echo "Name: " & objElement.ChildNodes(0).ChildNodes(0).NodeValue Wscript.Echo "Display Name: " &  objElement.ChildNodes(1).ChildNodes(0).NodeValue Wscript.Echo Loop
예, 압니다. 얽히고 설킨 줄거리가 등골을 오싹하게 하죠. objElement.ChildNodes(0).ChildNodes(0).NodeValue! 이런 걸 본 사람이 있기나 하겠습니까? 물론, 철저한 보안 유지를 위해 Scripting Guy조차도 이 시리즈의 결말을 몰랐습니다. 하지만 이제 그 비밀을 공개합니다.
더 진행하기에 앞서 1부(technetmagazine.com/issues/2007/11/HeyScriptingGuy)를 읽지 못한 독자를 위해 시리즈 전체 내용을 간략하게 짚어 보겠습니다. 1부에서는 Windows Server® 2003 R2, Windows Vista® 및 Windows Server 2008에서 새롭게 선보인 기술인 WinRM을 소개했습니다. 이 기능은 방화벽까지 통과할 수 있으며 인터넷상에서 컴퓨터를 쉽게 관리할 수 있습니다. 사실 WMI(Windows Management Instrumentation)에도 컴퓨터를 원격으로 관리하는 기능이 있었습니다. 하지만 WMI는 DCOM(분산 COM)을 원격 관리 기술로 이용합니다. 대부분의 방화벽에서 DCOM 트래픽을 차단한다는 점만 제외한다면 이 기술도 훌륭합니다. 물론 적절한 포트를 열어서 DCOM 트래픽을 허용할 수도 있지만 대부분의 네트워크 관리자는 이런 방법을 꺼리는 경우가 많습니다. DCOM을 위해 문을 열었다가 모든 종류의 악의적인 공격이 들어올 수 있는 문도 함께 열게 될까 우려하기 때문입니다.
따라서 WinRM은 "서로 다른 업체에서 제공한 운영 체제와 하드웨어의 상호 운용을 가능케 하는 방화벽 친화적인 표준 SOAP 기반 프로토콜인 WS 관리 프로토콜을 Microsoft식으로 구현한 것"입니다. 쉽게 말해 이제 HTTP 및 HTTPS와 같은 표준 인터넷 프로토콜을 사용하여 원격 관리를 수행할 수 있다는 의미입니다.
지난달에 언급했듯이, WinRM을 사용하면 원격 컴퓨터에서 손쉽게 WMI 정보에 연결하고 이를 검색할 수 있습니다. 그렇다면 이 기술이 절대적으로 완벽한 기술이라는 의미일까요? 꼭 그렇지만은 않습니다. 이미 지적했듯이, WinRM에서 데이터를 호출 스크립트로 다시 전송하면 데이터는 다시 XML 형식으로 반환됩니다. 말할 필요도 없이 XML은 시스템 관리자가 이에 대한 충분한 지식이 없다면 구문 분석하고 이용하기가 조금 까다롭습니다. 이런 점 때문에 WinRM에는 반환된 데이터를 더 읽기 쉬운 형식으로 변환하는 XSL 변환이 함께 제공됩니다.
이 기능은 출력 내용이 항상 다음과 같은 형식으로 나온다는 점을 제외하면 매우 훌륭합니다.
Win32_Service AcceptPause = false AcceptStop = true Caption = User Profile Service CheckPoint = 0 CreationClassName = Win32_Service
이것도 나쁘지는 않지만 결과가 항상 명령 창에 출력된다는 것이 문제입니다. 기본적으로 데이터를 텍스트 파일로 저장하거나 데이터베이스 또는 Microsoft® Excel® 스프레드시트에 기록할 수 없으며, 정보를 화면에 표시하는 것 이외의 다른 방식으로는 이용할 수 없습니다. 이건 그다지 좋은 점이라 할 수 없겠죠.
무엇보다 WMI 클래스의 속성을 선택한 수만큼만 반환하려는 경우 문제가 더 악화됩니다. 이것은 보통 네트워크 트래픽을 줄이기 위한 것입니다. 클래스의 모든 속성이 아닌 일부 속성만으로 작업할 경우 다음과 유사한 출력 내용이 표시됩니다.
XmlFragment DisplayName = Windows Event Log Name = EventLog

XmlFragment DisplayName = COM+ Event System Name = EventSystem
흥미롭지만 지금까지 보아온 것과는 달리 정보가 표시되는 모양이 미관상 그리 훌륭하진 않네요. 보고서 전체에 나타나는 머리글 XmlFragment가 특히 그렇습니다.
그러면 이를 어떻게 해결해야 할까요? XML 데이터를 구문 분석하고 서식을 지정하는 사용자 지정 코드를 작성하면 될까요? 그건 시스템 관리 스크립트 작성자가 그다지 반가워하지 않을 것 같습니다. 아니, 반가워 할까요?

어떤 일을 제대로 하려면 그 일을 직접 할 것
WinRM에서 반환된 원시 XML 데이터를 다루는 것은 보기보다 까다롭습니다. 이번 달에는 XML 데이터를 구문 분석하고 서식을 지정하는 간단한 방법 한 가지를 소개하려고 합니다. 여기서 사용하는 방법이 XML을 다루는 유일한 방법은 결코 아니지만 뭐, 상관 없습니다. 우리의 주된 목표는 XSLT 변환에 의존할 필요가 없다는 점을 보여 드리기 위한 것이니까요. 기본 개념만 파악하면 WinRM 데이터로 무궁무진한 작업을 할 수 있게 될 것입니다.
한 가지 유의할 점이 있습니다. 이 칼럼에서는 한정된 지면 때문에 그림 1에 소개된 스크립트의 대부분은 설명하지 않고 넘어갑니다. 하지만 스크립트 앞부분의 2/3 정도는 지난달 칼럼에서 자세히 설명했으므로 크게 문제되지 않을 것입니다. 여기서는 반환된 데이터로 실제 작업을 하는 부분인 스크립트의 마지막 1/3 부분을 집중적으로 설명하겠습니다.
잘 아시겠지만 여기서부터 설명하는 내용은 WSMan.Automation 개체의 인스턴스를 만들고, 원격 컴퓨터(이 경우 atl-fs-01.fabrikam.com)를 쿼리하고, 해당 컴퓨터에서 실행되고 있는 모든 서비스에 대한 정보를 수신한 후의 단계입니다. 반환된 XML 데이터를 읽고 처리하기 위해 Do Until 루프를 설정한 스크립트 줄부터 시작하겠습니다. 이 루프는 모든 데이터를 읽고 처리할 때까지 -또는 주제와 관련하여 얘기하자면, XML 파일의 AtEndOfStream 속성이 True일 때까지- 계속됩니다.
다음 코드 줄이 바로 그 부분이자 이번 달 칼럼에서 이야기할 부분입니다.
Do Until objResponse.AtEndOfStream
루프 안에서 가장 먼저 해야 할 일은 반환된 XML 데이터의 첫 번째 섹션을 ReadItem 메서드를 사용하여 읽는 것입니다. 지금은 WinRM으로 작업하면서 서비스 정보를 검색하고 있으므로 이 첫 번째 섹션은 컬렉션의 첫 번째 서비스에 대해 반환된 모든 데이터로 구성됩니다. XML 형식의 데이터를 strXML이라는 변수에 저장한 다음 Microsoft.XMLDom 개체의 인스턴스를 만듭니다. 그러면 실제로 작업을 할 수 있는 빈 XML 문서가 생성됩니다.
Set objXMLDoc = _ CreateObject("Microsoft.XMLDom")
빈 문서가 준비되면 Async 속성의 값을 False로 설정한 다음 loadXML 메서드를 호출합니다.
그러면 이런 의문이 들 수 있습니다. 왜 Async 속성의 값을 False로 설정할까요? 그리고 왜 loadXML 메서드를 호출할까요? 좋은 질문이지만 직접 생각해 보는 것이 좋습니다.
초보자를 위해 설명하자면 Async 속성은 스크립트가 XML 정보의 비동기 다운로드를 허용할 것인지 여부를 나타냅니다. 이 속성이 True이면 다운로드가 시작되고 다운로드가 완료되지 않았더라도 제어가 즉시 스크립트로 반환됩니다. 꽤 괜찮은 처리 방법인 것처럼 보일 수 있습니다. 하지만 이 경우 해당 스크립트는 필요한 모든 정보를 얻은 것처럼 다음 작업을 진행하게 됩니다. 이때 필요한 모든 정보를 얻지 못한 경우에는 문제가 발생합니다. 따라서 Async 속성을 False로 설정하는 것입니다.
참고로 말씀 드리자면, 물론 다운로드의 상태를 주기적으로 모니터하는 코드를 작성하여 스크립트가 너무 속성으로 진행되지 않도록 할 수도 있습니다. 이런 방법도 있지만 Async 속성을 False로 설정하는 편이 훨씬 더 쉽습니다. 이렇게 하면 스크립트는 다운로드가 완료될 때까지 중지됩니다. 즉, 다운로드가 시작되면 스크립트는 다운로드가 끝날 때까지 기다린 다음 다른 작업을 하게 됩니다.
loadXML 메서드는 그 이름에서 추측할 수 있듯이 잘 구성된(Well-Formed) XML 문서(또는 문서 부분)를 앞에서 만든 빈 문서로 로드합니다. loadXML 메서드의 유일한 매개 변수에 strXML 변수를 전달하고 메서드를 호출하기만 하면 됩니다.
objXMLDoc.loadXML(strXML)
결과는 어떻게 될까요? 이제 WinRM 데이터를 가상 XML 문서로 변환했습니다. 이는 표준 XML 메서드를 사용하여 해당 가상 문서의 구문 분석을 할 수 있음을 의미합니다.
다음으로는 XML 파일의 루트 요소에 대한 개체 참조를 만들기 위해 다음 코드를 사용해야 합니다.
Set objElement = objXMLDoc.documentElement
이 지점에서 재미있는 작업을 할 수 있습니다. 물론 재미라는 개념에 XML 파일의 구문 분석이 포함되는 사람의 경우입니다. 당연히 Scripting Guy는 여기에 포함됩니다.
다시 기억을 더듬어 보면, WQL(WMI Query Language) 쿼리(또는 WinRM 용어로 '필터')는 다음과 같습니다.
strFilter = "Select Name, DisplayName " & _ "From Win32_Service Where State = 'Running'"
여기서 볼 수 있듯이 Win32_Service 클래스에서 Name 및 DisplayName 이 두 가지 속성을 요청했습니다. (반환되는 데이터를 실행 중인 서비스로 제한하는 Where 절도 넣었습니다. 하지만 여기서는 문제될 부분이 없습니다.) 두 개의 속성을 요청했다는 점이 중요할까요? 이 요청의 순서가 중요할까요? 그럴 수 있습니다. 이에 대해 알아두는 것이 좋습니다.
이 기사를 작성하는 우리는 이 질문에 대한 답을 알고 있어야 합니다. 우리는 이 두 질문에 대한 답이 '예'라는 것을 알고 있습니다. WQL 쿼리에서 두 개의 속성을 요청했다는 사실이 중요한 걸까요? 예, 중요합니다. 클래스의 모든 속성에 대한 값을 반환하는 Select * From 쿼리와 반대로, 이 두 가지 속성 값만 반환되기 때문이지요.
그러면 이 두 가지 속성의 순서도 중요할까요? 물론입니다. 속성 이름을 지정하는 순서는 속성 값이 반환되는 순서와 같습니다. 각 속성 값은 루트 요소의 자식 노드(또는 섹션)로 반환되므로 이는 중요한 사항입니다. 어떤 속성 값이 첫 번째 자식 노드로 반환될까요? 쉬운 질문입니다. 이 경우 첫 번째 자식 노드는 Name 속성입니다. WQL 쿼리에 이 속성을 처음 나열했기 때문입니다. 그럼 두 번째 자식 노드로 반환되는 속성은 무엇일까요? 그렇습니다. 쿼리에서 두 번째 항목으로 나열한 DisplayName 속성입니다.
잠깐만요. 이 문제를 직접 풀었습니까 아니면 누군가 이 칼럼의 사본을 미리 빼돌려서 여러분에게 주었습니까? 음, 의심스럽군요.
어쨌든 Name 속성의 값은 쉽게 출력할 수 있습니다. 다음과 같이 첫 번째 ChildNodes(항목 0) 컬렉션에서 첫 번째 항목(항목 0)의 NodeValue를 참조하기만 하면 됩니다.
Wscript.Echo "Name: " & _ objElement.ChildNodes(0).ChildNodes(0).NodeValue
그러면 DisplayName 속성의 값은 어떻게 참조할까요? 이 경우에는 두 번째 ChildNodes(항목 1) 컬렉션에서 첫 번째 항목의 NodeValue를 참조합니다.
Wscript.Echo "Display Name: " & _ objElement.ChildNodes(1).ChildNodes(0).NodeValue
이 WQL 쿼리에 세 번째 속성(예를 들어 Status)이 있다면 어떻게 될까요? 이 경우에는 세 번째 ChildNodes(항목 2) 컬렉션에서 첫 번째 항목의 NodeValue를 참조하기만 하면 됩니다.
Wscript.Echo "Status: " & _ objElement.ChildNodes(2).ChildNodes(0).NodeValue
이렇게 마지막 속성까지 진행합니다.
이제 스크립트 출력은 다음과 같이 나타납니다.
Display Name: Windows Event Log Name: EventLog

Display Name: COM+ Event System Name: EventSystem
혼란스러운 XmlFragment 머리글을 제거하기는 했지만, 사실 기본 WinRM 출력과 크게 달라 보이지는 않습니다. 차이점이라면, 개별 속성 값으로 작업하기 때문에 기본 서식 지정으로 제한되지 않으며(DisplayName이 아니라 레이블 Display Name을 사용한다는 사실을 기억해 두십시오) 정보가 명령 창에서만 표시되는 제한도 없다는 점입니다.
이 데이터를 Excel 스프레드시트에 쓰고 싶으십니까? 이 역시 간단합니다. 우선 WinRM 스크립트에서 Enumerate 메서드 바로 뒤에 다음과 같은 코드 블록을 넣습니다. 이 코드 블록은 새 Excel 스프레드시트를 만들고 구성하는 코드입니다.
Set objExcel = _ CreateObject("Excel.Application") objExcel.Visible = True Set objWorkbook = objExcel.Workbooks.Add() Set objWorksheet = objWorkbook.Worksheets(1)

i = 2 objWorksheet.Cells(1,1) = "Name" objWorksheet.Cells(1,2) = "Display Name"
이제 원래의 Do Until 루프를 그림 2에 보이는 것으로 바꿉니다. 직접 결과를 확인하십시오.
Figure 2 새 Do Until 루프 (Close Figure 2)
Do Until objResponse.AtEndOfStream strXML = objResponse.ReadItem

  Set objXMLDoc = CreateObject("Microsoft.XMLDom") objXMLDoc.async=False objXMLDoc.loadXML(strXML)

  Set objElement = objXMLDoc.documentElement objExcel.Cells(i, 1) = objElement.ChildNodes(0).ChildNodes(0).NodeValue objExcel.Cells(i, 2) = objElement.ChildNodes(1).ChildNodes(0).NodeValue i = i + 1 Loop

WinRM, 3부?
이달 칼럼과 지난달 칼럼만 참조하셔도 WinRM 사용을 시작하기에는 충분합니다. 그게 저희의 바람이랍니다. WinRM은 안전과 보안은 유지하면서 컴퓨터를 훨씬 더 쉽게 원격 관리할 수 있도록 도와주는 새롭고 흥미로운 기술입니다. 이렇게 말하면 WinRM에 대한 기사가 3부까지 있다는 의미인지 궁금해 하는 독자가 있을 것입니다
죄송하지만 그 정보는 공개할 수 없습니다. 보안 문제 때문은 아니고요, 그저 지금으로서는 우리 Scripting Guy의 계획이나 의사 결정 절차 때문에 WinRM에 대한 다른 기사를 쓸 것인지 여부를 아직 알 수 없답니다. 흔히 하는 얘기지만, 채널을 고정하세요!
Dr. Scripto의 Scripting Perplexer
Doctor Scripto가 작은 사고를 치고 말았습니다. 스크립트를 방치하고 실수로 스크립팅 조각들을 마구 섞어버린 거지요. 그는 문제를 해결하기 위해 변수, 키워드, 기호 등을 모두 찾아서 알파벳 순서로 정렬했습니다. 하지만 이제 이를 다시 배열하여 스크립트 전체를 올바르게 구성해야 합니다. 시간이 어느 정도 걸리겠지만 다음 달 TechNet Magazine이 발간되기 전까지는 답을 찾을 예정입니다. 그동안 여러분도 이 뒤죽박죽 스크립팅 조각 모음을 하나의 스크립트로 맞추어 보시기 바랍니다. 행운을 기원합니다!
한 가지 작은 힌트를 드리자면, 최종 스크립트는 지정된 날짜 이전의 모든 파일을 로컬 컴퓨터에서 삭제합니다.

Dr. Scripto의 Scripting Perplexer
답: Clumsy Doctor Scripto, December 2007
예, Dr. Scripto는 자신의 스크립트를 원래 상태로 조합했습니다. 즉, 지정된 날짜보다 오래된 모든 파일을 로컬 컴퓨터에서 제거하는 정상적인 스크립트를 재구성했습니다:
strDate = "20060102000000.000000+000"

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colFiles = objWMIService.ExecQuery("Select * From CIM_DataFile Where CreationDate < '" & strDate & "'")
For Each objFile in colFiles
    Wscript.Echo objFile.Name
Next

The Microsoft Scripting Guys 이들은 Microsoft에서 고용되어 일하고 있는 Microsoft의 직원들이며 좋아하는 야구 경기와 기타 여러 활동을 하는 시간을 제외하고는 항상 TechNet 스크립트 센터를 운영합니다. 자세한 내용은 www.scriptingguys.com에서 확인하십시오.


 Security Watch: Windows 도메인 암호 정책
Security Watch
Windows 도메인 암호 정책
Derek Melber

Windows 도메인 관리자라면 도메인 사용자 계정에 대한 암호 정책과 관련된 제약 조건을 너무나 잘 알고 있을 것입니다. 그러나 Windows Server 2008의 등장으로 이러한 제약 중 일부는 사라질 것입니다. 그 가운데 여러 암호 정책을 구현할 수 없었던 문제가 이번 새 OS에서 어떻게 해결되었는지 살펴보겠습니다.
현재 Windows® 도메인을 실행 중이라면 Windows NT®, Windows 2000 Active Directory®, Windows Server® 2003 Active Directory 등 버전에 관계없이 도메인당 하나의 암호 정책만 적용할 수 있습니다. 실제로 이러한 제한은 암호 정책에만 국한되지 않고 계정 정책의 설정에도 영향을 줍니다. 그림 1에는 이러한 정책과 설정이 나와 있습니다.
Figure 1 계정 정책 (Close Figure 1)

암호 정책
최근 암호 기억
최대 암호 사용 기간
최소 암호 사용 기간
최소 암호 길이
암호는 복잡성 요구 사항을 충족해야 함
해독 가능한 암호화를 사용하여 암호 저장
계정 잠금 정책
계정 잠금 기간
계정 잠금 임계값
다음 시간 후 계정 잠금 수를 원래대로 설정
Kerberos 정책
사용자 로그온 제한을 실시
서비스 티켓 최대 수명
사용자 티켓 최대 수명
사용자 티켓 갱신 최대 수명
컴퓨터 시계 동기화 최대 허용 오차
이러한 정책 설정은 기본적으로 모든 도메인과 그에 연결된 사용자 계정에 적용됩니다. 이는 그룹 정책이 Active Directory 구조를 통해 상속되는 방식 때문입니다. 이러한 정책들이 도메인과 로컬 사용자 계정에 어떠한 영향을 미치는지 더욱 정확히 알려면 이러한 정책들이 어디에서 설정되고, 그룹 정책 상속이 다른 모든 사용자 계정에 어떠한 영향을 미치는지 이해하는 것이 중요합니다. 여기서 유의해야 할 점은 Kerberos 정책 설정은 도메인 사용자 계정에만 적용된다는 점입니다. 이것은 도메인 사용자 계정에서만 인증에 Kerberos를 사용하기 때문입니다. 로컬 사용자 계정은 인증에 NTLMv2, NTLM 또는 LM을 사용합니다.

계정 정책 설정
Active Directory 내부에서 그룹 정책은 전체 도메인에 대한 계정 정책을 설정하고 제어합니다. 이는 Active Directory 도메인을 처음 설치할 때 생성되며 기본 GPO(그룹 정책 개체)를 Active Directory의 도메인 노드에 연결함으로써 완성됩니다. 기본 도메인 정책이라 부르는 이 GPO는 계정 정책의 세 개 섹션 모두에 대한 기본 구성을 갖습니다. 그림 2는 Windows Server 2003 도메인의 암호 정책 항목에 대한 초기 설정을 보여 줍니다.
그림 2 Windows Server 2003 도메인의 기본 암호 정책
그림 2 Windows Server 2003 도메인의 기본 암호 정책
이 GPO의 설정은 모든 도메인 사용자 계정과 모든 도메인 컴퓨터에 대한 계정 정책을 제어합니다. 모든 도메인 컴퓨터(데스크톱과 서버)에는 로컬 SAM(보안 계정 관리자)이 있다는 점을 기억해야 합니다. 기본 GPO의 설정에 의해 제어되는 것이 바로 이 SAM입니다. 물론, 로컬 SAM에는 해당 컴퓨터의 로컬 사용자 계정도 들어 있습니다.
기본 도메인 정책의 설정은 Active Directory 구조를 통해 GPO를 통상적으로 상속함으로써 모든 도메인 컴퓨터에 영향을 미칩니다. 이 GPO가 도메인 노드에 연결되어 있으므로 해당 도메인의 모든 컴퓨터 계정이 그 영향을 받게 되는 것입니다.

기존 암호 정책의 제약 조건
여러 해 동안 엄격한 테스트가 이루어졌고 증거가 밝혀진 것도 없지만 현재 Windows Server 2003에서의 Active Directory 구현과 관련하여 암호 제어에 대한 수많은 오해들이 있습니다. 정책은 설계된 의도와 다른 방식으로는 작동하지 않는다는 점은 분명한 사실입니다.
그런데 많은 관리자들은 같은 도메인에 있는 사용자에 대해 여러 암호 정책을 갖는 것이 가능하다고 믿고 있습니다. 이들은 사용자가 GPO를 만들어 OU(조직 구성 단위)에 연결할 수 있다고 생각합니다. 즉, 사용자 계정을 OU로 옮기면 GPO가 해당 개체에 영향을 미칠 것이라 생각합니다. GPO 안에서 계정 정책은 암호의 최대 길이를 14자로 설정하는 등의 방식으로 더욱 안전한 암호 정책을 만들도록 수정됩니다. 그러나 몇 가지 이유로 인해 이러한 구성은 원하는 결과를 제공하지 않습니다. 첫째, 암호 정책 설정은 사용자 기반 정책이라기보다는 컴퓨터 기반 정책입니다. 설정의 토대가 그러하기 때문에 사용자 계정에는 영향을 미치지 않습니다. 둘째, 도메인 사용자 계정에 대한 계정 정책 설정을 수정하는 유일한 방법은 해당 도메인에 연결된 GPO 안에 있습니다. 계정 정책 설정을 변경하도록 구성된 OU에 연결된 GPO는 해당 OU 또는 그 하위 OU 안에 있는 컴퓨터의 로컬 SAM을 수정합니다.
두 번째 오해는 루트 도메인(Active Directory 포리스트의 최초 도메인)에 설정된 계정 정책 설정은 해당 포리스트의 자식 도메인으로 상속될 것이라는 생각입니다. 이 역시 사실이 아니며 이러한 방식으로는 해당 설정을 작동시킬 수 없습니다. 도메인과 한 도메인 안의 OU에 연결된 GPO는 다른 도메인의 개체에 영향을 미치지 않습니다. 이는 GPO가 연결된 도메인이 루트 도메인이라 해도 마찬가지입니다. GPO 설정의 적용을 다른 도메인의 개체로 확대하는 유일한 방법은 GPO를 Active Directory 사이트에 연결하는 것입니다.

새로운 암호 정책
방금 살펴본 바와 같이 기존 버전의 Windows에서는 사용자 계정 암호를 단순하고 간단한 방식으로 처리합니다. 즉, 모든 도메인 계정에 하나의 암호 규칙 집합만 적용하고, 계정 정책을 Active Directory의 도메인 노드에 연결된 그룹 정책 개체를 통해 관리합니다. 이러한 단순성은 Windows Server 2008에서 완전히 사라집니다.
Windows Server 2008과 이와 함께 제공되는 Active Directory 인프라에서는 전혀 다른 방식을 취합니다. 모든 도메인 사용자 계정에 하나의 정책만 설정되도록 허용하는 계정 정책을 GPO에 두는 방식 대신 이제 Active Directory의 더 세세한 부분에서 설정할 수 있도록 변경되었습니다. 또한, 계정 정책은 더 이상 컴퓨터 계정을 기반으로 하지 않습니다. 이제는 개별 사용자 및 사용자 그룹별로 암호 제한을 제어할 수 있습니다. 오랫동안 컴퓨터 계정에 대한 계정 정책을 다뤄왔기 때문에 Windows 관리자에게 이것은 근본적으로 새로운 개념일 것입니다.

Windows Server 2008의 계정 정책
Windows Server 2008에서는 기본 도메인 정책을 통해 계정 정책을 설정하지 않습니다. 실제로, 도메인 사용자 계정에 대한 계정 정책을 만들기 위해 GPO를 사용하지 않습니다. Windows Server 2008에서는 Active Directory 데이터베이스로 이동하여 수정 작업을 할 수 있습니다. 구체적으로 말하자면, ADSIEdit와 같은 도구를 사용하여 Active Directory 개체와 그에 연결된 특성을 수정할 수 있습니다.
이렇게 변경된 이유는 그룹 정책이 같은 도메인 안에서 여러 개의 암호를 사용하도록 설계되지 않았기 때문입니다. 도메인별로 여러 개의 암호를 구현할 수 있는 Windows Server 2008의 기능은 매우 뛰어난 기능이기는 하나 모든 사람들이 좋아할 만큼 사용하기 쉬운 기능은 아닙니다. 그러나 시간이 흐르면서 설정 구성을 위한 인터페이스도 액세스가 더 쉬워질 것입니다. 현재로서는 시스템을 변경하려면 마치 Active Directory 데이터베이스를 해킹하는 것 같은 방법을 취해야 합니다.
다른 방식을 선호한다면 계정 정책 설정을 수정하기 위해 굳이 ADSIEdit를 사용하지 않아도 됩니다. Active Directory 데이터베이스를 활용할 수 있는 기타 모든 LDAP 편집 도구를 사용할 수 있으며 심지어 스크립팅도 가능합니다. Windows Server 2008에서 암호 정책을 구현할 때는 과거와는 전혀 다른 방식을 취해야 합니다. 이 새로운 기능은 어느 사용자와 그룹이 어떤 암호 설정을 받게 될 것인지 고려해야 한다는 것을 의미합니다.
암호 길이뿐만 아니라, 최소/최대 사용 기간, 최근 암호 기억 등 암호 정책 설정에 수반되는 추가 제한 사항 역시 고려해야 합니다. 또한 사용자 잠금 정책 설정과 Kerberos 설정을 제어하는 방법도 고려해야 합니다. 현재의 계정 정책 설정과 Windows Server 2008의 Active Directory 데이터베이스에서 구성되는 계정 정책 설정 사이에는 일대일 관계가 성립됩니다. 그러나 이제는 각 정책 설정의 이름이 Active Directory 개체와 특성이므로 기존과 다르다는 점에 유의해야 합니다.
새로운 암호 설정을 구현하려면 암호 설정 컨테이너(LDAP 경로: "cn=Password Settings,cn=System,dc=domainname,dc=com") 아래에 msDS-PasswordSettings라는 이름의 PSO(암호 설정 개체)를 만들어야 합니다. 또한 현재 다루고 있는 도메인의 기능 수준을 Windows Server 2008로 설정해야 합니다. 이 새 개체 아래에 그림 3과 같은 몇 가지 특성에 대한 정보를 입력합니다.
Figure 3 Active Directory의 암호 특성 (Close Figure 3)

Active Directory 특성 이름 | 특성 설명
msDS-PasswordSettingsPrecedence | 사용자가 암호화 정책이 서로 다른 여러 그룹의 구성원일 경우 우선 순위를 설정합니다.
msDS-PasswordReversibleEncryptionEnabled | 해독 가능한 암호화 사용 여부를 전환합니다.
msDS-PasswordHistoryLength | 고유 암호를 몇 개 사용한 후에 이러한 암호를 재사용할 수 있는지 지정합니다.
msDS-PasswordComplexityEnabled | 암호에 요구되는 문자의 수와 유형을 지정합니다.
msDS-MinimumPasswordLength | 암호의 최소 길이를 지정합니다.
msDS-MinimumPasswordAge | 암호를 변경하기 전에 사용해야 하는 최소 기간을 지정합니다.
msDS-MaximumPasswordAge | 암호 변경을 요구받기 전에 사용할 수 있는 최대 기간을 지정합니다.
msDS-LockoutThreshold | 잘못된 암호 입력을 몇 번 시도하면 사용자 계정이 잠기는지 지정합니다.
msDS-LockoutObservationWindow | 잘못된 암호 횟수가 재설정될 때까지 걸리는 시간을 지정합니다.
msDS-LockoutDuration | 잘못된 암호 시도 횟수 제한을 넘은 계정을 잠금 상태로 유지할 기간을 지정합니다.
그림에서 볼 수 있듯이 계정 정책 설정과 관련된 모든 그룹 정책 설정은 특성으로 복제됩니다. 또한 우선 순위도 설정할 수 있습니다. 같은 도메인에 여러 개의 암호를 구현할 경우, 분명 충돌이 발생할 것이고 이를 처리할 수 있는 메커니즘이 마련되어 있어야 하므로 우선 순위 설정은 필수적입니다.

계정 정책 설정의 대상 지정
생성하는 각 개체에 대해 계정 정책이 각 사용자에 맞게 설정되도록 모든 특성을 입력해야 합니다. msDS-PSOAppliesTo는 정책 설정 집합을 받을 개체를 결정하는 새로운 특성입니다. 이는 특정 설정을 특정 사용자와 연결할 수 있게 하는 매우 중요한 특성입니다. 이 특성 아래의 목록에는 사용자 또는 그룹을 추가할 수 있지만 액세스 제어 목록을 작성할 때는 언제나 그렇듯 사용자 대신 그룹을 사용하는 것이 가장 좋습니다. 그룹이 더 안정적이고 눈에 잘 띄며 일반적으로 다루기 훨씬 쉽기 때문입니다.

환영할 만한 변화
우리는 오랫동안 같은 Active Directory 도메인 안에서 여러 개의 암호를 사용할 수 있기를 원해 왔으며 이제는 그것이 가능해졌습니다. 이제는 같은 도메인에 속한 모든 사용자를 암호와 관련하여 동일한 보안 수준으로 취급하는 일은 없을 것입니다. 예를 들어 이제는 일반 사용자에게는 8자리 암호를 사용하도록 하고 (관리자 권한을 갖고 있을) IT 전문가에게는 더 복잡한 14자리 암호를 사용하도록 할 수 있습니다.
물론, Active Directory 데이터베이스에서 계정 정책 설정을 수립 또는 수정하는 방식에 익숙해지는 데는 다소 시간이 걸릴 것입니다. 그러나 다행히 새로운 설정은 여러분에게 이미 익숙한 방식을 본떠 구성되었습니다. Windows Server 2008을 접하게 되면 이 새로운 설정부터 검토해보시기 바랍니다. 틀림없이 이 새로운 설정들을 가장 먼저 구성하게 될 것이기 때문입니다.

Derek Melber MCSE, CISM, MVP이며 독립 컨설턴트 겸 강사로 Active Directory, 그룹 정책, 보안, 데스크톱 관리를 중심으로 Microsoft 기술을 교육하고 전파하고 있습니다. 또한 Microsoft Windows Group Policy Guide(Microsoft Press, 2005) 등 몇 권의 IT 서적을 저술했습니다. 문의 사항이 있으면 derekm@braincore.net으로 연락하십시오.


 The Desktop Files: 가상 세계에서의 Windows 배포
The Desktop Files
가상 세계에서의 Windows 배포
Wes Miller

가상 컴퓨팅은 모든 곳에 존재합니다. 아직 가상 컴퓨팅을 활용하고 있지 않다면 지금부터라도 활용하는 것이 좋습니다. 가상화는 기본적으로 고유의 하드웨어 추상 계층을 생성하여 Windows Server 또는 Windows 클라이언트 운영 체제 등과 같은 여러 게스트 시스템을 호스트 시스템 사이에서 옮길 수 있게 함으로써 하드웨어 의존성을 줄여줍니다.
물론, 가상화는 게스트의 프로세서를 흉내 내는 것이 아니라는 점에서 에뮬레이션과는 다릅니다. 가상화는 단순히 호스트 시스템의 리소스를 게스트 시스템에서 액세스할 수 있는 방식으로 표시할 뿐입니다. 따라서 게스트 시스템은 호스트 시스템을 일반 시스템처럼 사용할 수 있습니다. 즉, 특정 OEM이 제작한 시스템에서 다른 OEM이 제작한 시스템으로 가상 게스트를 옮길 수 있으며, 이때 일반적으로 호스트의 하드웨어는 문제가 되지 않습니다. 그러나 몇 가지 유의할 점이 있습니다. 예를 들어 AMD CPU 공급업체의 프로세서를 사용하는 하드웨어에서 Intel의 CPU 프로세서를 사용하는 하드웨어로 게스트를 옮길 경우에는 사용 중인 가상화 기술에 따라 문제가 발생할 수 있습니다. 이러한 문제는 가상 컴퓨팅 기술이 호스트와 게스트 사이에 정보만 전달하기 때문입니다. 즉, PowerPC 기반 Macintosh에서 실행되는 Microsoft® Virtual PC의 경우처럼 게스트의 특정 CPU를 에뮬레이트하지는 않습니다.
다만 가상화는 주요 하드웨어 구성 요소를 게스트로 에뮬레이트합니다. 대부분의 경우, 이러한 에뮬레이션은 네트워킹, 비디오(일반적으로 에뮬레이트된 고급 GPU를 포함하지 않는 매우 제한된 장치), 대용량 저장 장치 등으로 한정됩니다. 이는 모두 여러 유형의 소프트웨어적으로 에뮬레이트된 장치를 게스트에 제공하는 방식으로 기능합니다. 필자가 작성한 칼럼을 오래전부터 읽어왔다면 이러한 장치들이 Windows® PE에서 관리하는 장치들과 같다는 점을 파악하실 것입니다. 가상화에서 그러한 장치들은 Windows에서 원하는 작업을 실제로 처리하기 위해서 반드시 갖춰야 하는 유형의 장치들입니다. 또한 모든 가상화 기술은 반드시 BIOS를 에뮬레이트해야 합니다. 가상화 기술은 또한 EFI(Extensible Firmware Interface)를 에뮬레이트할 수 있지만 현재 EFI 기반 운영 체제를 선택하는 경우는 극히 드물므로 활용도 또한 낮습니다. 이러한 모든 에뮬레이션을 통해 가상 게스트의 부팅이 가능해집니다. BIOS와 각 장치는 실제 장치를 소프트웨어적으로 에뮬레이트하여 게스트에 제공합니다. 이는 에뮬레이트된 장치들도 실제 장치들에 필요한 드라이버와 동일한 드라이버(Windows에서 제공하는 드라이버가 아닐 수도 있음)를 필요로 함을 의미합니다. 이 개념은 반드시 기억해둬야 합니다.
일부 가상화 기술에서는 USB 또는 USB 2.0 장치와의 연결도 가능하지만 여기에서는 자세히 다루지 않겠습니다. 그와 같은 USB 장치에 드라이버(프린터, USB 무선 NIC 등) 또는 일부 DirectX® 지원(대부분의 가상화 기술에서는 일반적으로 제공하지 않음)이 필요하다는 점을 제외하면, 그 작동에 있어 반드시 필요한 요건은 그리 많지 않습니다. 물론, USB 또는 기타 에뮬레이트되지 않는 장치에 대한 지원은 사용 중인 가상화 기술에 따라 다르다는 점을 유념해야 합니다. 새로운 장치를 함께 사용하기 전에 현재 사용 중인 가상화 제품의 한계(분명한 경계)를 반드시 알고 있어야 합니다.
현재 Windows에 대한 주요 가상화 기술 공급업체는 Microsoft와 VMware(vmware.com)입니다. 그리고 Parallels(parallels.com)와 같은 새롭고 유망한 공급업체들도 있습니다.
지금까지 가상화의 핵심적인 개념을 설명했으므로 이제부터는 가상화를 설정하는 방법, 흔히 발생하는 문제를 방지하는 방법, 사용자 환경의 여러 시스템에 가상화를 배포하는 방법에 대해 설명하겠습니다.

가상 배포
가상 시스템의 배포가 물리적 시스템의 배포와 꼭 달라야 할 이유는 없습니다. 그러나 곧 설명하겠지만 두 배포 방식이 서로 달라지는 중요한 이유들이 몇 가지 있습니다.
Windows NT® 초기 시절에는 설치 과정을 거쳐 배포해야 했습니다. 스크립트 처리도 가능했지만, 어쨌든 전체 과정을 거쳐야 했습니다. 설치한 후 해당 이미지를 여러 시스템에 복사하는 작업은 매우 편리한 개념이지만 전혀 지원되지 않았습니다.
그러나 마침내 Microsoft는 Windows NT 시스템의 디스크 복제를 지원하는 것이 합리적이라는 결정을 내렸습니다. 따라서 오늘날에는 물리적 시스템 배포에 활용할 수 있는 모든 방법을 가상 시스템 배포에도 적용할 수 있습니다. 따라서 Winnt32(또는 Windows Vista®와 Windows Server® 2008의 경우 setup.exe), Windows PE(1.x 또는 2.x, 이전 칼럼에서 설명한 것처럼 배포 중인 클라이언트에 따라 다름), RIS(원격 설치 서비스) 또는 WDS(Windows 배포 서비스), 또는 Sysprep(Windows NT 4.0에 도입된 배포를 위한 시스템 준비 도구) 및 선호하는 디스크 복제 기술(예: ImageX)을 사용할 수 있습니다.
그러나 물론, 그러한 작업은 특정 OS를 처음 배포할 때만 필수적입니다. 그 후에는 그냥 복사만 하기를 원할 수도 있을 것입니다. 그러나 제가 방금 언급한 것과 같은 디스크 기반 복제 방법에는 문제가 하나 있습니다.

Sysprep 사용
애초에 Microsoft에서 디스크 기반 복제를 지원하지 않기로 결정하게 된 데에는 Windows NT SID(보안 식별자)가 주된 요인으로 작용했습니다. 다행히 Sysprep을 통해 그 문제를 해결할 수 있습니다. 먼저 이 문제부터 살펴보겠습니다. support.microsoft.com/kb/314828에서 설명했듯이 SID는 개별 Windows 기반 컴퓨터를 식별하는 SID 구조 수정 번호(일반적으로 GUID)로 이루어집니다. 그리고 이 ID는 모든 로컬 계정에 대한 식별자의 루트 부분으로 사용됩니다. 로컬 계정은 RID(상대 식별자)라는 자체 고유 식별자를 가집니다. RID는 SID의 끝에 계정 ID가 연결되는 방식으로 구성됩니다. 따라서 두 ID의 조합이 로컬 계정의 ID가 됩니다.
이것이 왜 문제가 되는지는 Administrator SID S-1-5-21-191058668-193157475-1542849698-500을 예로 들어 설명하겠습니다. 여기서 S-1-5는 SID를 나타내는 설명자(S는 SID의 텍스트 표현의 대표 문자)이며 1과 5는 각각 Windows NT SID 수정 번호와 인증 기관 ID 값(여기서는 Windows Security)을 나타냅니다. 잘 알려진 Windows Administrator 계정 SID를 나타내는 500을 포함하여 나머지가 실제 SID입니다. 모든 Windows 설치에서 기본적으로 생성되며 삭제할 수 없는 Administrator 계정은 500으로 끝나는 SID를 가집니다. 설치 후 Windows에 추가되는 로컬 사용자 계정은 1000 이상 번호의 SID를 가집니다.
Windows Sysinternals에서 제공되는 PSGetSID를 사용하면 시스템의 특정 사용자 SID나 시스템의 SID를 열거할 수 있습니다. Windows Sysinternals는 PSTools에 관해 필자가 작성한 칼럼(technetmagazine.com/issues/2007/03/DesktopFiles)에 설명되어 있습니다. 그림 1에는 PSGetSID에서 필자의 가상 시스템 SID와 사용자 계정 SID인 1003이 출력된 결과가 나와 있습니다.
그림 1 가상 시스템 SID 및 사용자 계정 SID인 1003에 대한 PSGetSID의 출력
그림 1 가상 시스템 SID 및 사용자 계정 SID인 1003에 대한 PSGetSID의 출력
로컬 계정 RID가 이 SID에 기반을 두므로 시스템을 디스크 복제하거나 가상 시스템 이미지를 복사할 때 어떤 문제가 발생할지는 쉽게 예상할 수 있습니다. Sysprep에는 여러 유용한 기능이 많지만 주요 기능인 SID를 유지하는 기능을 통해 Windows 시스템이 고유하게 유지되는 주요 구성 요소 사본을 얻을 수 있습니다. 시스템 A와 시스템 B의 Administrator SID가 같다면 각 시스템의 사용자가 스스로를 같은 사용자로 아무 문제없이 식별할 것입니다. 시스템 A와 B의 모든 로컬 계정이 상대 시스템에 자신을 인증할 때도 같은 원칙이 적용됩니다. 더욱 문제가 되는 것은, 이 시스템들이 Active Directory®에 제공될 때도 같은 SID를 갖는다는 점입니다. 따라서 시스템 A에는 도메인 리소스에 대한 인증을 허용하되 시스템 B에는 허용하지 않을 경우 충돌이 발생하게 됩니다. B를 거절하도록 설정할 경우, 실제로는 A 역시 거절될 것입니다.
따라서 Sysprep을 사용하여 시스템의 SID를 재생성하는 것이 매우 중요합니다. 특히 시스템 이미지를 아주 쉽게 전파할 수 있는 가상 시스템 시나리오에서는 반드시 그렇게 해야 합니다. 또한 타사의 SID 변경 도구가 아닌, 오직 Sysprep만 사용해야 합니다. Sysprep은 가상 시스템을 포함한 시스템 복제 준비 용도로 Microsoft에서 설계, 테스트, 지원하는 도구입니다. 그림 2에는 시스템의 SID를 변경하기 전 Sysprep의 모습이 예로 나와 있습니다. 다음 단계에 시스템이 복제되도록 준비하는 경우라면 "Don't regenerate security identifiers(보안 식별자를 다시 생성하지 않음)" 옵션은 항상 해제되어 있어야 합니다.
그림 2 복제를 준비하는 경우 해제되어 있어야 하는 &quot;Don't regenerate security identifiers&quot; 옵션
그림 2 복제를 준비하는 경우 해제되어 있어야 하는 &quot;Don't regenerate security identifiers&quot; 옵션
또한 Sysprep은 SID를 새로운 ID로 업데이트할 뿐만 아니라 SID와 컴퓨터 이름을 반영하고 새로운 SID에 맞게 암호화를 변경하도록 인식되는 모든 개인 데이터 저장소를 수정합니다. IIS 메타베이스의 예약된 작업 데이터 저장소와 값(IIS가 설치된 경우)을 예로 들 수 있습니다.
Sysprep은 또한 시스템의 모든 NIC를 강제로 삭제하고 네트워크 구성 데이터로 대체합니다. 네트워크 구성으로 인해 레지스트리에서 NIC가 삭제되고, 해당 NIC의 관계는 NIC의 하드웨어 ID를 기반으로 하므로(가상 시스템에서 가상 시스템으로 이동하는 경우 외에는 깨질 경우가 많음) Sysprep은 이러한 일반적으로 버려진 데이터를 지웁니다.
Sysprep은 또한 시스템에서 모든 Active Directory 구성원 정보를 지웁니다. 따라서 그 작업 과정에서 불가피하게 시스템을 도메인에서 제거해야 합니다. 이를 통해 방금 새로운 SID를 받은 시스템을 도메인에 안전하게 가입시킬 수 있습니다. 일부 SID 변경 유틸리티에서는 시스템을 도메인에서 제거하지 않고 SID를 변경할 수 있지만 이 방식은 안정적이지 않으며 안전하지도 않습니다. 도메인 구성원인 컴퓨터에서 반드시 Sysprep을 실행해야 하는 상황이라면 Sysprep을 실행하기 전에 도메인에서 컴퓨터를 제거하거나 Sysprep을 실행하여 대신 처리하도록 하십시오.
DC(도메인 컨트롤러)를 가상화하는 경우 이와 관련하여 유념해야 할 한 가지 사항은 DC로 승격되지 않았으며 도메인에 가입되지 않은 독립 실행형 서버 시스템은 복제해야 한다는 것입니다. Windows Server 2003 Small Business Server Edition을 제외하고는 DC를 안전하게 디스크 복제할 수 없습니다. 새로운 DC를 안전하게 만들려면 도메인에 가입되고 DC로 승격될 준비가 된 서버의 디스크 이미지를 만들어야 합니다. 단일 포리스트/단일 서버인 매우 특수화된 SBS 인스턴스의 경우를 제외하고 Sysprep은 DC의 SID를 안전하게 변경하는 방법을 알지 못합니다.
마지막으로 Sysprep은 SID를 변경하고 도메인에서 시스템을 제거하는 작업 외에도 시스템의 이름을 변경합니다.
가상 시스템의 이미지를 생성하거나 단순히 복사하는 경우에도 위의 작업을 모두 수행해야 한다는 것은 다소 부담스럽게 들릴 수도 있습니다. 그러나 이러한 작업은, 특히 네트워크에서 같은 도메인에 속한 다른 물리적 또는 가상 시스템과 함께 또는 자신의 사본과 함께 이러한 시스템을 사용하는 경우에는 더욱 중요합니다.
가상 시스템을 복제할 때 Sysprep을 사용하지 않는다면 수많은 문제(Active Directory 또는 기타 네트워킹 충돌)가 발생할 것이 거의 확실하며, 그 가운데 상당수는 예상치 못한 문제일 것입니다. 예를 들어, 가상 이미지가 해킹에 매우 취약하게 됩니다. 하나가 해킹되면 다른 이미지에도 액세스가 허용될 것이기 때문입니다.

드라이버 및 하드웨어 추상화 계층
가상 이미지에 포함된 가상 장치는 Windows용 "기본 제공(in-box)" 드라이버를 갖고 있지 않을 수 있다고 언급한 바 있습니다. 따라서, 한 저장소 버스 드라이버에서 다른 저장소 버스 드라이버로 가상 이미지를 옮길 때 심각한 0x0000007B 드라이버 오류가 물리적 하드웨어를 다룰 때와 마찬가지로 쉽게 발생할 수 있으므로 배포 작업을 수행할 때 또는 Sysprep을 이용하여 디스크 이미지를 배포할 때는 장치에 맞는 드라이버를 항상 준비해 두어야 합니다. 이것은 NIC의 경우에도 마찬가지입니다. 대부분의 가상화 제품은 비교적 보편적인 가상 장치를 제공하고자 하지만 추가 드라이버는 여전히 필요할 것입니다.
복잡한 HAL(하드웨어 추상화 계층) 역시 무시할 수 없습니다. 가상화 기술에서 지원하여 ACPI(고급 구성 및 전원 인터페이스) 다중 프로세서(intel.com/technology/iapc/acpi 참조)를 지원하는 가상 시스템을 만들 수 있다면 이상적이겠지만, HAL 사이에서의 변환은 일반적으로 지원되지 않습니다(구체적인 내용은 support.microsoft.com/kb/309283 참조). 그러나 일부 가상화 기술이나 더욱 중요하게도 많은 마이그레이션 기술에서는 비 ACPI Windows 설치를 ACPI Windows 설치로, 그리고 그 반대로도 안전하게 옮길 수 있다고 주장합니다. 그것은 사실이 아니며 이렇게 설치된 Windows는 문제 발생 시 Microsoft에서 지원하지 않습니다. 앞에서 언급한 지원 웹 페이지에 나와 있는 제한 사항은 가상화된 시스템에도 똑같이 적용됩니다. 그림 3에는 ACPI 유니프로세서 HAL을 사용하여 실행되는 가상 시스템의 장치 관리자에서 HAL이 어떻게 표시되는지 예가 나와 있습니다. 이것은 다중 프로세서 시스템과 교환이 가능하므로 단일 프로세서와 혼동하지 말아야 합니다.
그림 3 가상 시스템의 장치 관리자에 표시된 HAL
그림 3 가상 시스템의 장치 관리자에 표시된 HAL

기타 변경 사항
변경할 수 있는 것은 변경하고 변경할 수 없는 것은 받아들일 것
물리적 시스템과 가상 시스템 사이의 마이그레이션을 고려할 때는 변경할 수 있는 것과 할 수 없는 것을 기억해야 합니다. Windows 설치에서 변경할 수 있는 사항은 다음과 같습니다.
  • HAL - 단, 유니프로세서와 다중 프로세서 사이에서 마이그레이션할 경우에만 가능하며, 이 경우에도 전원 구성은 동일하게 유지해야 합니다.
  • 대용량 저장소 컨트롤러 - 쉽지는 않지만 대부분의 물리-가상 마이그레이션 솔루션에서는 이미 자체적으로 이를 시도하고 있습니다. 대부분의 공급업체에서는 IDE 및 SCSI 저장소 솔루션을 제공하고 있습니다. 한 시스템에서 다른 시스템으로의 이전이 그렇게 쉬운 것은 아니므로 배포 시 현명하게 선택하십시오. 일반적으로, SCSI를 선택하는 것이 장치 안정성이 더 높습니다. 대부분의 SCSI 장치 에뮬레이션 구현 시스템에서 그러합니다.
  • 네트워크 컨트롤러 - 가상-가상 마이그레이션 시나리오에서는 같은 공급업체의 기술을 사용하는 경우에만 일반적으로 네트워크 컨트롤러가 동일한 것으로 처리됩니다.
Windows 설치에서 변경할 수 없는 사항은 다음과 같습니다.
  • HAL - 동일한 전원 구성을 사용하는 경우 위에서 언급한 경우를 제외하고는 변경이 불가능합니다. 변경이 가능한 마이그레이션 솔루션을 사용하여 변경하더라도 Windows 설치가 안정적이라고 간주해서는 안 됩니다. 게다가 이러한 설치는 Microsoft의 지원을 받을 수 없습니다.

SID와 컴퓨터의 이름 외에도, 사용 중인 가상 컴퓨팅 기술에 특정한 일부 값도 변경해야 합니다. 특히 MAC 주소(네트워크 장치의 고유 ID)를 변경해야 합니다. 또한 많은 가상 응용 프로그램 역시 고유 식별자를 갖고 있습니다. 대부분은 자체 컴퓨터 구성 파일에 이러한 정보를 저장하므로, 그 항목들을 조작하고 유효성을 유지하는 방법이 궁금할 것입니다. PXE(Pre-Boot eXecution Environment)를 지원하는 대부분의 가상화 제품들은 고유 ID를 기반으로 SMBIOS UUID를 조정하므로, 시스템을 도메인에 가입시키고자 한다면 고유 ID를 변경하거나, (지원될 경우) 가상화 소프트웨어에서 대신 변경하도록 할 필요성이 더 커집니다. 그렇지 않으면 GUID가 충돌하는 경우 WDS 또는 RIS 클라이언트 시스템을 관리하는 것이 불가능해질 수 있습니다. 필자가 다뤄본 가상화 솔루션의 대부분은 MAC 주소가 중복될 경우 심각한 네트워킹 문제를 일으킬 수 있으므로 가상 시스템을 단순히 옮기는 것이 목적이 아니라면, 가상화 소프트웨어에서 자동으로 지원하지 않을 경우에는 MAC 주소를 변경하는 것이 매우 중요합니다.
배포할 가상 시스템을 준비할 때 유념해야 할 다른 구성 요소로는 연결된 디스크 또는 스냅숏이 있습니다. 이들은 사용하는 가상화 솔루션에 따라 차등 디스크 또는 기타 다른 이름으로 불릴 수도 있습니다. 그러나 Sysprep을 실행하여 시스템을 준비하고 가상 시스템과 관련하여 스냅숏을 갖고 있거나 기타 되돌릴 수 있는 기술이 있다면 복제할 때 이미지의 안전성과 안정성, 보안성을 유지하기 위해 이들을 반드시 없애야 합니다. 스냅숏 또는 기타 "디스크 변경 취소" 기술을 활용하는 경우 스냅숏을 되돌리는 작업은 원본 가상 시스템을 기반으로 생성된 하나 이상의 시스템이 다른 시스템 또는 원본 소스 시스템과 충돌하는 상황으로 퇴행하는 것을 의미할 수 있습니다. 따라서 스냅숏 또는 차등 디스크가 관련된 경우에는 미리 Sysprep이 실행되도록 해야 합니다.

최적화
대부분의 가상화 기술에는 호스트에서 게스트와 상호 작용하는 성능과 환경을 개선하는 데 도움이 되는 가상 시스템 추가 기능 또는 도구가 있습니다. 여기에는 일반적으로 마우스 및 키보드 입력을 최적화하는 작업 등을 통해 성능을 향상시키며 복사 및 붙여넣기 또는 기타 호스트와 게스트 간의 상호 작용을 개선하는 기능이 포함됩니다. 배포 전에 가상 시스템에 이러한 도구의 최신 버전을 설치하십시오.
또한 클라이언트 메모리를 게스트 OS에 최적으로 구성하는 것뿐만 아니라 게스트 OS가 배포될 호스트의 환경에도 맞게 구성해야 합니다. 1GB의 RAM을 사용하도록 설정된 Windows XP 이미지를 그 정도의 RAM이 없는 호스트 시스템에 배포하는 상황은 원치 않을 것입니다.
또한 오늘날 대부분의 가상화 기술이 갖고 있는 한계도 기억해야 합니다. 사용자에게는 가상 시스템에 연결된 주변 기기와의 상호 작용 방식뿐만 아니라 게스트 OS에서 실행 가능한 응용 프로그램이 어느 것이냐 하는 문제(예를 들어 대부분 DirectX 9 또는 10을 지원하지 않거나 기존 버전을 제한적으로 지원함)도 중요하기 때문입니다. 사용자들은 이러한 문제가 무엇을 의미하는지 또는 어떤 식으로 드러나는지 모를 수 있습니다. 일부 응용 프로그램은 이러한 문제를 제대로 처리하지 못합니다.

호스트 문제
호스트에서 실행되는 것이 정식 운영 체제인지 아니면 하드웨어에서 직접 실행되는 Type 1 Hypervisor인지 하는 문제에 관계없이, 가상화 기술이 실행되는 호스트 PC와 관련해서는 신경 써야 할 일이 일반적으로는 그리 많지 않습니다. 대부분의 가상화 기술은 게스트 OS가 호스트를 전혀 또는 거의 알 필요가 없도록 설계됩니다. 그러나 한 호스트에서 다른 호스트로 옮겨진 게스트에 문제가 발생할 경우에 대비하여 어느 호스트가 사용되고 있는지는 파악해야 합니다. 또한 사용 중인 가상화 공급업체의 제품이 특정 플랫폼에서 어떠한 한계를 갖고 있는지도 알고 있어야 합니다. 한 호스트에서 다른 호스트로 옮길 수 있지만 그 과정에서 호스트 OS의 Type 2 Hypervisor(가상화 응용 프로그램)의 일부 기능을 잃거나 얻을 수도 있습니다.

기타 배포 메커니즘
관련 Sysprep 링크
다음은 Sysprep과 관련하여 많은 도움이 되는 문서입니다.
  • Sysprep을 사용하여 이미지 기반 설치 디자인
  • Sysprep 도구를 사용하여 Windows XP의 성공적인 구축을 자동화하는 방법
  • 시스템 준비 도구(Sysprep.exe)를 사용하여 디스크 복제를 수행하는 방법
  • 서로 다른 컴퓨터에 시스템 준비 도구 사용

Sysprep 또는 디스크 복제 기능을 사용하거나 단순히 Sysprep을 실행하여 가상 시스템을 복사하는 작업은 가상 시스템 배포에 당연히 활용되는 방법이지만, 다른 방법들도 있습니다. 사실, 이미지를 사용하든 설치 프로그램을 사용하든 물리적 CD가 아닌 ISO 파일을 사용하는 것이기 때문에 가상화에서는 Windows PE를 사용하는 것이 물리적 시스템을 사용하는 것보다 쉬울 수 있습니다. 일부 가상화 기술은 DVD 미디어를 제대로 처리하지 못하는 경우가 있으므로 가상화 공급업체에 지원 여부를 확인해야 합니다. winnt32 또는 setup.exe(Windows Vista 또는 Windows Server 2008의 경우)를 사용할 수 있지만 특별한 이점은 없습니다. 다른 Microsoft 배포 기술, 예컨대 ADS(자동 배포 서비스)를 이용한다면 가상화 기술에서 마치 RIS 또는 WDS를 사용하는 것처럼 네트워크 기반 배포를 시작할 수 있는 PXE를 지원합니다.

마이그레이션
마지막으로, 실제로 전체 PC를 마이그레이션하는 방법 외에 USMT(사용자 상태 마이그레이션 도구)도 있습니다. USMT를 이용하면 사용자의 설정을 물리적 클라이언트에서 새로운 가상 시스템으로 쉽게 옮길 수 있습니다. 따라서, 사용자가 기존 데이터와 설정을 새로운 가상 시스템으로 마이그레이션하기를 원한다면 여러분은 쉽게 Windows XP에서 파일과 설정을 가져와서 UNC에 저장한 다음 새로운 가상 시스템으로 전달할 수 있습니다.

Wes Miller 텍사스 오스틴에 거주하고 있습니다. 이전에는 오스틴에 위치한 Winternals Software에서 근무했으며 Microsoft에서 프로그램 관리자 및 Windows 제품 관리자로 일하기도 했습니다. 문의 사항이 있으신 분은 technet@getwired.com으로 연락하시기 바랍니다.


 Field Notes: 바뀔 수 있는 미래
Field Notes
바뀔 수 있는 미래
Romi Mahajan

철학자 이자 경제학자인 Karl Marx는 자신의 저서 중 한 곳에서, 19세기 유럽의 산업화와 자본주의 부흥으로 인해 야기된 사회적 범주 사이의 관계 변화를 지적하면서 "고착화된 모든 것은 스러져 사라진다"고 썼습니다. 경계와 범주는 결코 완전하게 고착화되지 않는다는 이 강력한 견해는 특히 기술 분야에서 다양한 형태와 맥락으로 설득력을 발휘하고 있습니다. 기술 분야에서 변화하지 않는 것은 변화 그 자체뿐입니다.
급속히 변화하는 이 업계에서, 소비자 주도 기술의 대두만큼 변화의 속도와 그로 인해 우리가 직면하게 된 과제를 잘 보여 주는 사례는 없습니다. 실제로, IT는 '소비자 주도'로 되어 왔으며, 변화의 주요 지표들은 개인의 영역에서 명백히 드러나면서 직업적인 영역과 일상적인 영역 양쪽에 거대한 영향을 미치고 있습니다. 이 현상은 여러 형태로 나타나고 있습니다.
  1. 웹 2.0의 세계는 인터넷을 통한 읽기와 쓰기를 중심으로 합니다. 인터넷에 글을 쓴다는 것은 소비자로서 작가의 역할을 수행함을 뜻합니다.
  2. 소비자 응용 프로그램과 기술은 비즈니스에 '후광(halo)' 효과를 창출하고 있습니다.
  3. 소비자 주도의 IT에 따라 인터넷의 핵심 설계가 마련되고 있으며 이에 대한 테스트가 이루어지고 있습니다.
  4. 지원 센터 등의 IT 조직은 가정용 기술과 기업용 기술의 경계가 사라지고 있다는 사실을 인식하고 이에 대비 및 대응하고 학습해야 합니다.
  5. 의사 결정을 내리는 사람들은 모두 직업인인 동시에 소비자입니다.
  6. 개인이 선호하는 기술은 거의 언제나 기업용 제품이 아니라 소비자용 제품입니다.
몇 가지 사례만 살펴보아도 알 수 있듯이, 그 함의는 심대하며 여러 범주들은 서로 뒤바뀔 수 있습니다. IT 회사에 근무하는 제 친구의 말에 따르면, 자기 회사 지원 센터에 접수되는 문의 전화 중 8%는 iTunes 업데이트와 관련된 내용이라고 합니다. Cisco의 백서 "엑사바이트 시대(The Exabyte Era)"는 도입부에서 두 가지 사항을 언급합니다. 하나는 스트리밍 비디오 용량 과잉으로 인해 인터넷이 붕괴되는 상황은 벌어지지 않고 있다는 점, 다른 하나는 YouTube는 시작에 불과하다는 점입니다. NDP Group 보고서에 따르면 Apple Corporation은 2007년 3월 소매 노트북 컴퓨터 시장의 거의 10%를 차지했습니다. iPod의 후광 효과가 나타난 것입니다. Microsoft는 게임, 음악, 디지털 사진, 비디오 호스팅 등의 분야에 막대한 투자를 감행하고 있습니다. 또한 요즘 기업들은 Second Life에서 회의 모임을 갖고 있습니다.
게다가, 기술 브랜드는 매우 심오한 수준으로 격상되고 일반화되고 있습니다. 사람들은 어지간한 일은 Google로 처리하며, iPod가 화제의 중심이 되고 "myspace"에 자신에 관한 내용을 올리며 여가 시간을 Xbox®와 함께 보냅니다. 사람과 기술 사이에 정서적 관계가 형성되고 있으며, 이 관계의 효과는 사무실에서 집으로 다시 사무실로, 그리고 그러한 장치와 응용 프로그램, 웹사이트, 커뮤니티를 만든 기업에 대한 호감으로 전이됩니다. 좋다, 그저 그렇다, 나쁘다와 같은 인식이 형성되면 그 인식 자체가 개인적, 직업적 현실 속에서 우리와 함께 하게 됩니다.
한 개인과 관련을 맺는 것은 무엇인가 하는 문제는 복잡한 주제입니다. 그리고 기업이 메시지 조절, 친근감 표시, 고객에 대한 섬세한 관리 등의 과제를 동시에 충족하기 위해서는 문화의 근본적인 변화가 필수적입니다. 역할의 심층적 세분화가 이루어지기 전에는 포괄적인 메시지가 마케팅의 중심이었습니다. 반대로, 최근에는 특성에 맞춰 분화된 메시지 전달이 대세를 이루면서 직위, 소속 계층, 회사 규모, 특정 기술 등의 범주에 따라 엄밀한 분류가 가능해졌습니다. 그러나 한편으로는, 고착화된 모든 것은 스러져 사라지기 마련이며 개인/소비자로서의 구체적 현실 속에서 사람들에게 호소하는 것은 고객과의 관계를 형성하고 경쟁에서 앞서 나가기 위한 유일한 수단이라는 점이 간과되어 왔습니다.
바뀔 수 있다는 것은 교체가 가능하다는 것이고 범주 사이에 고착된 구분이 없다는 것을 의미합니다. 달리 말해, 소비자 기술이라는 개념과 기업용 기술이라는 개념을 더 이상 뚜렷이 구분할 수 없다는 것입니다. 소비자 주도의 IT는 현실이 되었습니다. 그리고 미래는 바뀔 수 있습니다.

Romi Mahajan은 Microsoft 기술 사용자 및 플랫폼 마케팅 팀의 마케팅 담당 이사입니다. Romi는 정치, 환경, 기술, 사회학 등 여러 분야에서 폭넓은 저술 활동을 벌여 왔습니다.


 Windows Confidential: 조이스틱은 전자레인지가 아니다.
Windows Confidential
조이스틱은 전자레인지가 아니다.
Raymond Chen

최근 동료 중 한 사람이 블로그에 올린 글 Audio Fool을 읽으면서 필자는 여러 해 전부터 마음을 불편하게 해 온 실수 하나를 떠올렸습니다. DirectInput® 힘 피드백 조이스틱 인터페이스 개발 작업이 진행 중이던 때, 제안된 인터페이스의 세부 사항에 대한 논의와 의견 수렴을 위해 저희는 워싱턴 주 레드먼드의 Microsoft 본사로 조이스틱 제조업체를 초대했습니다.
많은 것들이 논의되었지만 제 뇌리에 남아 있는 것은 주기적 힘을 주기로 표현해야 하는가 아니면 주파수로 표현해야 하는가에 관해 합의가 이루어지지 않았다는 점입니다. 참석했던 업체 관계자 중 한 분은 자기 회사에서 이미 주기적 힘을 주파수로 명시한 드라이버를 제작했고 변경을 원치 않는다며 소란을 피웠습니다. 그 회의가 새로운 인터페이스의 세부 규격을 논의해서 정하는 자리였다는 점을 감안한다면, 대체 어느 업체가 자사 드라이버를 전혀 변경하지 않고 회의를 마칠 것을 기대할 수 있을까요?
하지만 이 업체의 불만이 너무나 강했던 바람에 마침내 우리가 포기하고 주기적 힘의 정도를 주기 대신 주파수로 명시하기로 합의했습니다. 어느 쪽이든 크게 문제가 될 것 같지는 않았습니다. 초당 진동 수 10회의 주파수가 나타내는 힘은 10분의 1초의 주기를 가진 힘과 동일합니다. 주기와 주파수는 서로를 반대로 표현한 것에 불과합니다.
그런데 실상 그것은 정확한 사실이 아니었습니다. 주기는 밀리초(ms) 단위로 표현되며 1ms의 동적 범위는 50일까지입니다. 50일이라는 주기는 인간의 시간 감각으로는 인지할 수 없으며, 1ms라는 주기는 너무 빨라서 주기적 현상이라기보다는 음조로 인지됩니다.
반면, 주파수는 헤르츠(Hz)로 표현되며 1Hz의 동적 범위는 초당 40억 사이클까지입니다. 조이스틱으로 음악을 재생하는 것도 아니고, 생소하게 느껴지십니까? 전자레인지가 발산하는 주파수 대역으로까지 힘을 높인다고 상상해 보십시오!
문제는 주파수 대역의 최고역대 수치는 실용적으로 전혀 쓸모없는 높은 수준까지 표현되는 반면, 최저역대 수치 표현은 너무 부족하다는 점입니다. 비행 시뮬레이터는 주기가 비교적 길어 힘을 주기로 표현하는 것이 매우 좋은 것으로 드러났습니다. 자세한 물리학적 근거는 모르지만, 제가 들은 바로는 항공기 조종사가 다뤄야 하는 물리 효과는 몇 분 단위로 조종간에 작용하는 느린 주기적 힘이라고 합니다. 항공기는 매우 느린 수직 정현 곡선을 따라 비행하는 경향이 있으므로, 조종사는 이 경향을 상쇄하는 조종을 통해 평탄한 비행을 유지할 수 있습니다. 힘을 주기로 표현할 경우, 비행 시뮬레이터 프로그램의 힘은 120,000ms 주기로 명시할 수 있습니다. 그러나 주파수로 표현할 경우, 0.0083Hz가 되는데, 이 수치는 문제의 드라이버 인터페이스에서 표시할 수 있는 최저역대 주파수 1Hz보다 훨씬 낮은 수치입니다. 따라서 비행 시뮬레이터에서 요청할 수 있는 가장 느린 힘은 매초 단위로 반복되는 힘이고, 그러한 힘은 비행 시뮬레이터 프로그램에서 재현하고자 하는 물리적 효과에 비해 여전히 아주 빠른 속도의 힘이 되는 것입니다.
이후 여러 해 동안 이 문제로 계속 마음이 불편했기 때문에, 최근에 저는 힘 전달에 대한 설명서를 찾아보았습니다. 그런데 놀랍게도, DIPERIODIC 구조체에서는 주기적 효과를 주파수 대신 주기 단위로 표시하고 있는 것으로 나타났습니다. (또한 마이크로초 단위를 채택하고 있었습니다. 이제는 비행기 조종은 물론 음악도 재생할 수 있다는 뜻입니다.) 실수가 시정되었든가 제 기억력이 노화로 감퇴하고 있든가 둘 중 하나이겠지요. 어느 쪽이든 그 실수에 대해서는 더 이상 마음 쓰지 않아도 되겠습니다. 그런 실수가 있었다고 하더라도 말입니다.

Raymond Chen은 The Old New Thing 웹 사이트와 동명의 저서(Addison-Wesley, 2007)에서 Windows의 역사와 Win32 프로그래밍에 대해 다루고 있습니다.