 TechNet Magazine August 2007

TechNet Magazine August 2007

System Center: SMS의 진화: 강력하고 새로운 시스템 관리 솔루션

시스템 관리가 그 어느 때보다 간편해질 전망입니다. 필자와 함께 System Center Configuration Manager 2007을 살펴보면서 소프트웨어 업데이트 배포, 모바일 장치 관리 및 시스템 구성 유지 관리와 같은 핵심 작업을 어떻게 단순화할 수 있는지 확인해 보십시오.

John Orefice System Center: 지사에 응용 프로그램 및 업데이트 배포

Configuration Manager 2007의 새로운 기능 중 하나인 지사 배포 지점은 일견 사소한 추가 기능처럼 보일 수 있습니다. 그러나 좀 더 자세히 살펴보면 이 기능이 지사의 소프트웨어 배포를 관리하는 데 매우 중요한 여러 기능을 제공한다는 것을 알 수 있습니다.

Steve Rachui System Center: System Center Essentials 2007 시작

중소기업에 맞게 설계된 System Center Essentials는 모니터링, 관리 및 문제 해결 시스템을 하나로 통합한 솔루션입니다. 지금부터 네트워크에 Essentials 2007을 설치 및 구성하는 방법에 대해 자세히 살펴보도록 하겠습니다.

David Mills System Center: 탁월한 서버 모니터링 기능을 제공하는 Operations Manager 2007

MOM의 새로운 버전인 Operations Manager 2007에서는 새로운 관리 인터페이스, 향상된 보고 기능, 기간 업무(LOB) 응용 프로그램 지원, 새로운 보안 옵션 등 다양한 측면이 개선되었습니다.

Pete Zerger System Center: MOM을 Operations Manager 2007로 마이그레이션

Operations Manager 2007로 전환할 준비가 되셨습니까? 아키텍처 자체가 변경되었기 때문에 기존 버전의 MOM에서 간단히 사용 중 업그레이드를 수행할 수 있는 방법은 없습니다. 대신, 여기에서 제시하는 마이그레이션 계획 중 하나를 따르십시오.

Andy Dominey System Center: Microsoft SoftGrid를 이용한 응용 프로그램 가상화

응용 프로그램 가상화는 사용자 환경 향상에서 시스템 관리 단순화에 이르기까지 다양한 이점을 제공합니다. Microsoft SoftGrid를 통해 가상 응용 프로그램을 구현하고 기존 인프라에 적용하여 시간과 비용을 절약하는 방법에 대해 자세히 확인해 보십시오.

Ahmer Sabri and Kedar Shah From The Editor: 동적 시스템 및 인프라 최적화

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

Greg Steen SQL Q&A: 잠금 검색, 대용량 쿼리, I/O 통계 및 기타

Edited by Nancy Michell Utility Spotlight: BGInfo

컴퓨터 이름, IP 주소, 게이트웨이, 사용 가능한 디스크 공간 등 PC를 파악하는 데 필요한 모든 정보를 한곳에서 확인할 수 있다면 얼마나 편리할까요? Sysinternals에서 무료로 제공하는 이 도구를 사용하면 가능합니다.

Lance Whitney The Cable Guy: Windows Vista의 IPv6 자동 구성

IPv6은 주소 공간을 32비트에서 128비트로 확장한다는 것 외에 다른 면에서도 의의가 있습니다. 이번 달 칼럼에서는 주소 구성 프로토콜을 사용하지 않고도 IPv6 호스트가 자동 구성되는 원리를 살펴보도록 하겠습니다.

Joseph Davies Windows PowerShell: 필터링의 유용성

파이프라인이 cmdlet에만 사용되는 것은 아닙니다. Windows PowerShell 파이프라인을 사용하여 유용한 필터링 기능을 스크립트에 추가하는 방법을 살펴보겠습니다.

Don Jones Hey, Scripting Guy!: 소개

Active Directory를 사용하는 경우 사용자에게 givenName, displayName, userPrincipalName, distinguishedName 등의 다양한 ID가 할당됩니다. 시스템 관리자는 이 모든 사용자 관련 정보를 어떻게 파악할까요? 물론 스크립트를 사용해야죠.

The Microsoft Scripting Guys Security Watch: Windows의 PKI 기능 향상

Windows Vista와 Windows Server 2008의 Windows PKI 플랫폼은 고급 알고리즘, 실시간 유효성 검사 및 향상된 관리 효율성을 지원합니다. 새로운 PKI 기능, 비용 절감 방법 및 보안 향상 효과에 대해 확인해 보시기 바랍니다.

John Morello The Desktop Files: RDP 익히기

RDP(원격 데스크톱 프로토콜)는 사용자가 시스템을 원격으로 액세스할 수 있게 하는 기능으로 Windows의 새 버전이 나올 때마다 향상되는 유용한 기술입니다. 원격 데스크톱의 개요를 보면서 여러 장점과 제한 사항을 살펴보겠습니다.

Wes Miller Field Notes: IM 면접

사원을 신규 채용해야 할 자리는 하나뿐인데 전 세계에서 수많은 지원자가 몰려 들었다면 어떻게 지원자를 추려내야 할까요? 이 경우 IM을 통한 면접이 해결책이 될 수 있습니다. 여기 한 개발자의 성공 사례를 소개합니다.

Nathan G. Jensen Windows Confidential: Windows 탐색기에서 텍스트를 사용할 수 없는 이유

Windows 탐색기에서 파일 목록을 복사한 다음 해당 파일의 파일 이름만 텍스트로 붙여 넣을 수 없는 이유는 무엇일까요? 과거 Windows 팀에서 이 기능을 구현하려고 시도했지만 생각대로 되지는 않았습니다.

Raymond Chen


 System Center: SMS의 진화: 강력하고 새로운 시스템 관리 솔루션
System Center John Orefice

SMS의 진화: 강력하고 새로운 시스템 관리 솔루션
한 눈에 보기:
  • 운영 체제 배포
  • 소프트웨어 업데이트 관리
  • 바람직한 구성 관리

Systems Management Server(SMS) 2003은 전세계 관리자들에게 중요한 구성 관리 및 소프트웨어 배포 도구로 자리잡았습니다. 이제 Microsoft는
새로운 버전의 엔터프라이즈 관리 솔루션을 System Center Configuration Manager 2007이라는 새 이름으로 내놓으면서 다양한 신기능을 선보이고 있습니다.
System Center는 복잡한 IT 인프라의 일상적인 관리 업무를 보다 경제적으로 손쉽게 수행하도록 지원하는 Microsoft 제품군의 하나입니다. System Center는 MOF(Microsoft® Operations Framework) 및 ITIL(Information Technology Infrastructure Library)의 자동화 기술과 모범 사례를 기반으로 구축된 솔루션으로, 조직 내 모든 수준에서 사용할 수 있습니다.
Configuration Manager 2007은 System Center 제품군의 일부입니다. System Center Data Protection Manager는 엔터프라이즈 시스템 백업 및 복구 기능을 제공합니다. System Center Operations Manager는 시스템 사전 모니터링 및 자동화 기능을 제공합니다. System Center Capacity Planner는 인프라 배포의 용량 계획과 가상 분석에 사용할 수 있습니다. 이 외에도 다양한 도구들이 지속적으로 추가되고 있습니다. 자세한 내용은 www.microsoft.com/systemcenter를 참조하십시오.
이 기사에서는 최신 베타 릴리스를 기준으로 Configuration Manager 2007에서 선보일 예정인 새로운 기능과 향상된 기능을 몇 가지 소개합니다. 그 과정에서 기대를 한 몸에 받고 있는 이번 릴리스에서 어떤 점을 기대할 수 있는지 살펴보고, 조직에서는 어떻게 Configuration Manager를 이용하여 시간과 비용을 절감할 수 있는지 알아보겠습니다.

새로운 관리 사용자 인터페이스
SMS 1.0이 릴리스될 당시부터 사용자들이 가장 많이 원했던 SMS의 기능은 새롭게 향상된 UI였습니다. 이에 Microsoft는 몇 가지 측면에서 System Center Configuration Manager 2007 관리 UI를 개선했습니다. 이러한 새로운 기능을 제공하기 위해 C# 및 Microsoft .NET Framework로 설계되고 MMC(Microsoft Management Console) 3.0 기술을 기반으로 실행되는 새로운 콘솔이 Configuration Manager 2007에 추가되었습니다. 또한 SMS 2003과 마찬가지로 SDK를 통한 UI 확장이 가능하므로 콘솔 사용자가 직접 필요한 추가 기능을 만들 수 있습니다.
그림 1은 새로운 콘솔의 Computer Management 노드가 확장된 모습으로, 새로운 관리 기능을 모두 보여 주고 있습니다. 뿐만 아니라 모양이 새롭게 바뀐 SMS Site Configuration 섹션에는 Configuration Manager를 설치하고 나서 사용하기 전에 완료해야 할 일반적인 작업들이 간단히 설명되어 있습니다. Links and Resources 섹션에는 콘솔에서 자주 사용하는 기능을 손쉽게 탐색할 수 있는 관련 작업이 포함되어 있습니다.
그림 1 Configuration Manager 관리 인터페이스
그림 1 Configuration Manager 관리 인터페이스
이러한 새 콘솔이 제공하는 이점과 기능으로는 복수 항목 선택, 컴퓨터 그룹 관리에 유용한 끌어서 놓기, 콘솔의 항목이 물리적 방식이 아닌 가상의 방식으로 구성되어 있는 검색 폴더, 현재 섹션에 해당하는 작업을 수행하는 데 사용되는 Actions(작업) 창, 운영 체제 이미지와 같은 특정 항목의 요약 정보를 표시하는 Preview(미리 보기) 창, 소프트웨어 배포 등의 특정 작업에 대한 정보가 요약된 홈 페이지, 간편한 탐색이 가능하도록 향상된 체계적인 구조 등이 있습니다.
앞서 언급했듯이 Actions 창은 새롭게 개선된 콘솔의 주요한 향상 기능 중 하나로, 현재 사용 중인 콘솔 섹션에 적합한 상황별 작업이 나열됩니다. 예를 들어 All Systems(모든 시스템) 컬렉션이 표시되어 있으면 Actions(작업) 창에 Update Collection Membership(컬렉션 구성원 업데이트), Install Agent(에이전트 설치)(그림 2 참조) 등의 작업이 나타납니다.
그림 2 현재 보기에 따라 다르게 표시되는 작업
그림 2 현재 보기에 따라 다르게 표시되는 작업
뿐만 아니라 Configuration Manager 2007에는 홈 페이지라는 새로운 개념이 추가되어 Software Updates(소프트웨어 업데이트), Software Distribution(소프트웨어 배포) 또는 Desired Configuration Management(원하는 구성 관리)와 같은 기능의 상태를 간단히 확인할 수 있습니다. 따라서 보고서를 실행하거나 다른 곳에서 데이터를 찾아보지 않고 콘솔에서 기능 상태를 확인할 수 있습니다. 홈 페이지의 예는 제품의 기능들을 소개하면서 하나씩 살펴보도록 하겠습니다.

서버 역할 및 배포 지점(DP)
Configuration Manager 2007에는 여기서 소개하는 여러 가지 새 기능에 사용하기 위해 새로운 서버 역할이 몇 가지 추가되었습니다. 이러한 역할로는 FSP(Fallback Status Point), PSP(PXE Service Point), Branch Office DP(Distribution Point), SMP(State Migration Point), SUP(Software Update Point), SHV(System Health Validator)가 있습니다. 이러한 새 역할도 다른 모든 SMS 및 Configuration Manager 서버 역할과 마찬가지로 용량 계획만 제대로 수립하면 한 서버에서 모두 호스트할 수 있습니다.
Branch Office DP는 두 가지 면에서 기존의 DP 역할과 다른 중요한 역할입니다. 첫째로, 반드시 서버 운영 체제에 설치할 필요가 없습니다. Windows Vista®나 Windows® XP 같은 운영 체제에도 설치할 수 있습니다. 이는 클라이언트 운영 체제에 설치할 수 있는 유일한 Configuration Manager 역할로서 로컬 서버가 없는 지사의 경우나 경비를 절감하고 관리 부담을 덜기 위해 IT 부서에서 소규모 지사의 서버를 제거하려는 경우에 특히 유용합니다. Windows XP 또는 Windows Vista를 실행하는 컴퓨터밖에 없는 이러한 경우에 Branch Office DP 역할을 사용하면 클라이언트가 패키지를 로컬에서 사용할 수 있을 때는 WAN을 통해 패키지를 가져오지 않으므로 WAN 트래픽이 줄어듭니다.
Branch Office DP 역할이 표준 DP 역할과 다른 또 하나의 특징은 다른 DP를 연결할 수 있다는 것입니다. 기존의 배포 지점 복제 데이터는 기본 사이트에서 보조 사이트로 갈 때만 제한하거나 예약할 수 있습니다. 이 때문에 많은 기업들이 밤에만 패키지를 지사로 복제하게 되어 이러한 패키지가 로컬에 배포될 때까지 소프트웨어 배포가 지연되는 경우가 많았습니다.
Branch Office DP는 BITS(Background Intelligent Transfer Services)를 사용하여 다른 DP에서 정보를 다운로드합니다. 이는 특히 지사에 Configuration Manager 보조 사이트가 없을 때 지사와 중앙 데이터 센터 DP 간 WAN 연결 대역폭을 제한하려는 경우 유용합니다. 그림 3은 Branch Office DP에 표준 DP를 만드는 데 사용되는 새 DP Properties(DP 속성) 대화 상자입니다.
그림 3 Branch Office DP 구성
그림 3 Branch Office DP 구성
SMS 2003에서는 사이트 서버에서 배포 지점으로 패키지 파일 델타 복제가 가능한 복제 기술을 선보였습니다. 이 기술은 몇 개의 작은 파일로 구성된 SMS 패키지의 경우 문제 없이 작용합니다. 예를 들어 SMS 관리자가 파일을 하나만 변경하거나 큰 SMS 패키지에 포함된 작은 파일을 몇 개만 변경하려는 경우 전체 패키지가 아니라 패키지 내의 변경된 파일만 복제되는 것입니다.
Configuration Manager 2007에 이르러 운영 체제 배포가 주를 이루면서 인프라 및 WAN 연결 전반에서 운영 체제 이미지 패키지와 기타 크기가 큰 패키지를 가능한 한 효율적으로 복제해야 할 필요성이 대두되었습니다. 이러한 요구에 맞추어 Configuration Manager 2007에는 사이트 서버에서 사이트 서버로, 사이트 서버에서 DP로, DP에서 Branch Office DP로의 이진 델타 복제 기능이 추가되었습니다.
먼저 몇 가지 응용 프로그램이 미리 설치된 새로운 Windows Vista 배포 사례를 예로 들어 보겠습니다. 이 패키지는 크기가 6GB이며, WIM(Windows Imaging Format) 이미지이므로 6GB짜리 단일 파일이기도 합니다. 앞서 설명한 대로 SMS 2003에서 설정을 변경하거나 새로 릴리스된 2MB짜리 패치를 추가하기 위해 새 WIM 이미지를 여는 경우, 이미지가 단일 WIM 파일이므로 6GB SMS 패키지 전체를 DP로 복제해야 합니다. 반면, Configuration Manager 2007의 이진 델타 복제 기능을 사용하면 WIM 이미지 패키지에서 설정을 변경하거나 단일 패치를 추가할 때 전체 6GB가 아닌 2MB짜리 패치 또는 설정만 인프라에 복제됩니다.

모바일 장치의 일반 프로세스
Microsoft는 SMS 2003을 릴리스한 직후 Windows CE 및 Pocket PC용 모바일 장치를 관리하는 DMFP(장치 관리 기능 팩)를 릴리스했습니다. 최근 들어 엔터프라이즈 조직 내에서 모바일 장치가 보편화되자 모바일 장치 관리의 중요성이 커지게 되었습니다. 이러한 추세에 따라 Configuration Manager 2007은 SMS 2003 DMFP를 개선하고, 서버, 랩톱 및 데스크톱 컴퓨터를 관리하는 방식과 매우 유사한 방식으로 Windows Mobile® 스마트 폰, Pocket PC 폰 등의 모바일 장치를 관리할 수 있는 새로운 통합 솔루션을 제공합니다.
모바일 장치의 기본 관리 기능에는 하드웨어 및 소프트웨어 인벤토리, 파일 수집 기능, 소프트웨어 배포, 암호 및 보안 정책 관리 설정 등이 있습니다. 이제는 Configuration Manager 2007 인터넷 기반 클라이언트 관리 기능을 사용하여 인터넷뿐만 아니라 인트라넷을 통해서도 모든 장치를 관리할 수 있습니다. 이는 회사 LAN에 연결되는 횟수가 아주 적은 스마트 폰과 같은 장치에 유용합니다.
에이전트 배포 프로세스도 개선되었습니다. 무선 클라이언트 업그레이드가 지원되는 것은 물론 Configuration Manager 콘솔을 통해 클라이언트 배포를 자동화할 수도 있습니다.

유지 관리 시간대
필자가 만난 엔터프라이즈 고객 중에는 중요한 데스크톱과 서버의 유지 관리 시간대를 미리 정의해 둔 고객이 많았습니다. 또한 평상시 근무 시간 중에 최종 사용자의 작업을 방해하지 않고 2007 Microsoft Office 시스템처럼 용량이 큰 응용 프로그램을 배포하는 방법에 대해 자주 자문을 구하기도 했습니다.
Configuration Manager 2007에서는 유지 관리 시간대라는 새로운 기능이 제공됩니다. 이 기능을 사용하면 특정 컴퓨터 그룹의 설치를 실행할 시간대를 정의할 수 있습니다. 따라서 정규 업무 시간이나 사용자에게 불편을 주는 시간에 패키지를 설치하는 데 따른 부정적인 영향을 걱정하지 않고 알림을 필수 사항으로 만들 수 있습니다.
2007 Office 시스템 패키지 배포를 예로 들어보겠습니다. 그날의 업무에는 영향을 미치지 않으면서 최종 사용자에게 응용 프로그램을 최대한 빨리 배포해야 한다고 합시다. 이 경우 오후 8:00 - 오전 6:00와 같은 유지 관리 시간대를 설정하여 시스템에서 설치를 실행할 수 있는 시간을 지시할 수 있습니다. 특정 일자에 특별한 사유로 인해 이 유지 관리 시간대에 시스템을 사용할 수 없는 경우가 발생하면 Configuration Manager는 업무에 예기치 않은 영향을 주지 않도록 유지 관리 시간대에 지정된 다음 시간까지 기다립니다. 뿐만 아니라 알림 수준에서 유지 관리 시간대를 무시할 수 있기 때문에 어떤 제한이 있더라도 중요한 업데이트를 최대한 빨리 배포할 수 있습니다.

운영 체제 배포
운영 체제 배포 기능은 Configuration Manager 2007에서 단일 기능으로서는 가장 중점을 둔 분야입니다. Microsoft는 서버 플랫폼과 워크스테이션 플랫폼에 운영 체제를 배포하는 주요 수단으로서 Configuration Manager를 설계했습니다. OS 배포 관리 방식을 근본적으로 변경하기 위해 SMS 2003 OSD(운영 체제 배포) 기능 팩의 유용한 기능들을 별도로 Configuration Manager 2007에 통합했습니다.
알다시피 Windows Vista에서는 운영 체제 배포에 새로운 WIM(Windows 이미징) 형식이 사용됩니다. 이 형식을 사용하면 다양한 이점이 있습니다. 우선, Configuration Manager 2007이 WIM 이미지 형식을 원래 그대로 가져오므로 관리자가 콘솔에서 직접 이미지 작업을 수행하고 배포할 수 있습니다.
Configuration Manager에 새로 추가된 다른 중요한 배포 기능으로는 Task Sequencer가 있습니다. Microsoft Solution Accelerator for BDD(Business Desktop Deployment)에 익숙한 사람이라면 Task Sequencer가 Configuration Manager에서 사용할 수 있는 기능 및 옵션과 매우 유사하다는 사실을 알 수 있을 것입니다. 하지만 한 가지 중요한 차이점이 있습니다. 바로 더 이상 운영 체제 이미지를 배포하거나 캡처하기 위해 스크립트를 작성하지 않아도 된다는 점입니다. 또한 운영 체제 배포 프로세스도 완전히 자동으로 진행된다는 이점이 있습니다.
Task Sequencer는 배포 전에 이전 OS에서 실행해야 할 단계(사용자 상태 마이그레이션 및 응용 프로그램 설정 전송), 새 운영 체제 배포 단계(포맷, 디스크 분할, 제품 키, 사용자 이름, 회사, 라이선스 설정, 드라이버 설치), 새 시스템을 배포한 후에 실행해야 할 단계(추가 응용 프로그램 설치, 업데이트 설치, 사용자 상태 마이그레이션) 등 OS 배포 과정 전반에 걸쳐 실행해야 할 모든 단계를 파악하는 데 도움을 줍니다. 그림 4는 이 기능의 예로서 Windows Vista 배포 시 활용할 수 있는 몇 가지 Task Sequence Editor 기능을 보여 줍니다.
그림 4 운영 체제 배포를 위한 단계 편집
그림 4 운영 체제 배포를 위한 단계 편집
그림 5에 나와 있는 것과 같이 Configuration Manager 2007에는 Task Sequencer 외에도 향상된 운영 체제 배포 기능이 몇 가지 있습니다. 예를 들어 Configuration Manager는 장치 드라이버 관리 기능이 있는 x86 및 x64 플랫폼에서 PXE(Pre-Boot Execution Environment)를 사용한 BMD(Bare-Metal Deployment)를 지원합니다. 조직에서 장치 드라이버 관리 옵션을 사용하면 하드웨어별로 관리해야 할 이미지의 수를 크게 줄일 수 있습니다. Windows Vista WIM 이미지 형식을 통해 제공되는 단일 이미지 지원과 함께 사용하면 운영 체제를 배포할 때 시간과 비용을 확실히 절약할 수 있습니다.
Figure 5 운영 체제 배포 기능 (Close Figure 5)

시나리오 | SMS 2003 | Configuration Manager 2007
종단 간 배포 | 예 | 예
완전 자동화 | 예 | 예
제거 후 로드 방식 업그레이드 | 예 | 예
PXE를 사용한 BMD(Bare-Metal Deployment) | 느슨한 RIS(원격 설치 서비스) 통합 | WDS(Windows 배포 서비스)와의 기본 통합
직접 비교 | BDD 스크립트 | 예(기본 제공 State Migration Point 사용)
전체 오프라인 배포 | 아니요 | 예
Windows Vista 업그레이드 계획 | 아니요 | 예
전체 서버 배포 | 아니요 | 예
장치 드라이버 관리 | 아니요 | 예

소프트웨어 업데이트 관리
Configuration Manager 2007의 다른 여러 가지 기능과 마찬가지로 소프트웨어 업데이트 관리 기능도 크게 개선되었습니다. Configuration Manager는 모든 소프트웨어 업데이트 및 원하는 구성 관리 정보를 위한 새로운 상태 기반 고 우선 순위 채널을 만들어 업데이트와 정규 패키지가 관리되는 에이전트에 배포되는 방식을 분리합니다. 따라서 소프트웨어 업데이트를 배포하거나 관리되는 워크스테이션, 랩톱 또는 서버에서 패치 상태를 수신할 때 다른 소프트웨어 패키지로 인해 작업이 중단되지 않습니다.
또한 상태 기반 소프트웨어 업데이트 관리 방식을 사용하기 때문에 패치 및 업데이트 상태가 하드웨어 인벤토리 검사에 의존하지 않게 되고, 결과적으로 현재 사용되는 ITMU(Inventory Tool for Microsoft Updates)와 검사 카탈로그가 더 이상 필요하지 않습니다. 대신 Configuration Manager는 소프트웨어 업데이트 엔진 및 데이터베이스로서 백 엔드에서 WSUS(Windows Server Update Services)를 실행하는 새로운 SUP(Software Update Point) 서버 역할을 사용합니다.
WSUS를 사용하면 한 곳에서 Configuration Manager의 모든 업데이트를 관리할 수 있습니다. 이는 곧 Microsoft 플랫폼을 위한 일반 업데이트, 드라이버 및 기타 소프트웨어 패키지 등 Microsoft Update를 통해 제공되는 모든 콘텐츠를 다운로드할 수 있음을 의미합니다. 뿐만 아니라 Microsoft는 파트너에게 이 방법으로 소프트웨어 업데이트를 릴리스할 것을 권장하고 있습니다. Adobe와 Citrix도 SMS 2003 R2에서 ITCU(Inventory Tool for Custom Updates) 목록을 게시하고 있는 수많은 회사 중 하나이며 Configuration Manager 전환을 위해 이러한 방식의 도입을 계획하고 있습니다.
이 새로운 소프트웨어 업데이트 엔진은 업데이트 상태를 실시간에 가깝게 제공하므로 보고 기능과 홈 페이지 보기가 향상됩니다. 사용자 지정된 이러한 보기에서는 IT 인프라 전반 또는 특정 컴퓨터 그룹의 패치 상태를 그래픽 차트로 빠르게 확인할 수 있습니다. 그림 6은 소프트웨어 업데이트 관리용으로 구성된 새로운 홈 페이지 보기 중 하나를 통해 특정 게시판의 패치 적용 상태 데이터를 얼마나 손쉽게 확인할 수 있는지를 잘 보여 줍니다.
그림 6 소프트웨어 업데이트 상태 보기
그림 6 소프트웨어 업데이트 상태 보기
마지막으로, 소프트웨어 업데이트 배포 템플릿은 새 업데이트를 시스템 또는 그룹에 배포하는 단계를 크게 줄여 줍니다. 이 기능은 소프트웨어 업데이트 배포 템플릿을 사용하여 시스템을 다시 시작할지 또는 설치를 실행하기 전 클라이언트가 DP에서 로컬로 패치를 다운로드하도록 할지 여부 등과 같은 일반적인 구성 정보를 저장함으로써 SMS 2003의 ITMU에서 필요했던 18단계를 Configuration Manager 2007에서 단 6단계로 줄였습니다.

바람직한 구성 관리
구성 관리 역시 Configuration Manager 2007에서 크게 향상된 뛰어난 기능 중 하나입니다. 2006년 가을에 릴리스된 SMS 2003 Desired Configuration Monitoring은 Configuration Manager 2007 Desired Configuration Management에서 제공되는 주요 기능 중 많은 부분을 제공했습니다. Desired Configuring Monitoring에 대한 자세한 내용은 TechNet Magazine 기사, microsoft.com/technet/technetmag/issues/ 2006/09/HighStandards를 참조하십시오. 그림 7에는 두 가지 특정 구성 기준에 대한 준수 여부를 보여 주는 Desired Configuration Management 홈 페이지가 나와 있습니다.
그림 7 바람직한 구성 기준 준수 보고
그림 7 바람직한 구성 기준 준수 보고
Configuration Manager의 Desired Configuration Management를 설계하는 데 가장 중요한 역할을 했던 것은 Microsoft 고객을 대상으로 한 조사입니다. Microsoft 고객은 대부분의 서비스 가동 중단 문제가 중요한 서버 및 데스크톱에서 잘못 구성된 운영 체제나 응용 프로그램 때문에 발생한다는 것을 보여주었습니다. Configuration Manager의 Desired Configuration Management 기능을 사용하면 관리자가 시스템에 대한 기준 검사를 주기적으로 실행하여 구성 흐름을 간단히 파악할 수 있습니다. 이러한 기준은 CI(구성 항목)를 사용하여 만들어지고 조직의 컴퓨터 그룹에 대한 구성 준수 정보를 제공합니다.
Desired Configuration Management를 사용하면 구성 흐름을 파악하는 것 외에 규정 준수 보고 및 변경 유효성을 확인하는 데에도 도움이 됩니다. 대부분의 조직에서는 SOX(Sarbanes-Oxley), PCI DSS(Payment Card Industry Data Security Standard), HIPAA(Health Insurance Portability and Accountability Act) 등의 규정 준수 여부를 보고해야 합니다. Configuration Manager 2007은 Desired Configuration Management를 통해 필요한 보고서를 제공할 수 있도록 지원합니다.
Desired Configuration Management의 작동 방식을 살펴보면, 먼저 관리자가 CI(컴퓨터에서 검색되고, 적용되고, 제거되는 구성 단위)를 정의합니다. CI가 정의되면 하나 이상의 CI로 구성 기준을 만들 수 있습니다. 이러한 기준은 Configuration Manager 컬렉션에 할당되어 규정 준수 모니터링 및 규정 준수 보고에 사용됩니다.
CI는 Active Directory®, 파일 메타데이터, 스크립트 결과, SQL Server™에 저장된 데이터, 소프트웨어 업데이트 데이터, WMI, XML, 레지스트리 값, IIS 메타데이터, Microsoft 설치 프로그램 존재 여부 및 구성 등 컴퓨터의 여러 가지 측면을 파악할 수 있습니다. 이렇게 다양한 위치에서 수집된 정보는 Configuration Manager 데이터베이스에 저장되고 시스템이 규정에 맞는지 여부를 확인하는 데 사용됩니다.
흥미로운 것은 Desired Configuration Management 프로세스와 Configuration Manager 2007을 통해 새 업데이트를 배포하는 프로세스가 완전히 통합되었다는 점입니다. 새로운 소프트웨어 엔진과 마찬가지로 Desired Configuration Management 데이터에도 상태 기반의 고 우선 순위 채널이 사용됩니다. 이 두 가지 중요한 기능이 통합됨에 따라 관리자는 업데이트 배포 프로세스의 일부로 새로운 Desired Configuration Management 기준을 정의하거나 기존 업데이트를 새 업데이트로 대체할 수 있게 되었습니다.

인터넷 기반 클라이언트 관리
컴퓨터의 네트워크 연결이 너무 오래 끊겨 SMS의 컴퓨터 개체가 쓸모없어진 적이 있지 않습니까? 필자가 동료들에게 물어본 바로는 이러한 일이 빈번하게 발생하는 것 같습니다. 다행히도 Configuration Manager 2007에는 인터넷 기반 클라이언트 관리 기능이 새로 추가되었습니다. 이 기능은 Microsoft Office Outlook®이 VPN(가상 사설망)을 사용하지 않고 HTTPS를 통해 Exchange Server와 통신하는 방식과 유사합니다. 간단하게 설명하자면 VPN 연결을 준수할 필요 없이 클라이언트 컴퓨터와 좀 더 안전하게 통신할 수 있게 되었음을 의미합니다.
인터넷 기반 클라이언트 관리 방식에서는 인터넷에서 인트라넷의 컴퓨터와 동일한 제어 수준으로 컴퓨터를 관리할 수 있습니다. 이 기사에서 설명하는 모든 기능은 인터넷 기반 클라이언트 관리 기능과 문제 없이 작동하지만 운영 체제 배포, Wake-On-LAN 및 원격 도구는 다른 포트를 사용하여 통신하고 SSL 또는 TLS를 통해 터널링될 수 없으므로 예외입니다. 인터넷 기반 클라이언트 관리 기능이 중요한 역할을 하는 좋은 사례로는 식당, 소매점, 주유소의 POS 장치, 직원의 가정용 컴퓨터, 외근이 잦은 현장 영업 사원이나 컨설팅 팀 등이 있습니다.
Configuration Manager 2007 인프라에서 인터넷 기반 클라이언트 관리 기능을 사용하기 위해서는 몇 가지 요구 사항이 있습니다. 먼저 Configuration Manager를 통해 관리되는 디지털 인증서에 할당할 PKI(공개 키 인프라)가 필요합니다. 디지털 인증서에 PKI를 할당하면 Configuration Manager 서버와 모든 관리 에이전트 간에 상호 인증을 사용하여 수신하는 데이터가 암호화되어 있는지, 그리고 신뢰할 수 있는 출처에서 전송된 것인지를 확인할 수 있습니다. 또한 Configuration Manager 서버와 모든 인터넷 기반 클라이언트 간의 연결 지점 역할을 하는 SSL 종결자도 필요합니다. Microsoft Internet Security and Acceleration(ISA) Server 2006은 이러한 요구 사항을 지원하는 소프트웨어 기반 솔루션입니다.
인터넷 기반 클라이언트 관리에는 새로운 FSP(Fallback Status Point) 서버 역할이 사용됩니다. 인터넷 기반 에이전트에서 오류가 발생하여 정상적으로 통신이 이루어지지 않거나 인증서가 만료되면 에이전트는 조직의 경계 네트워크에서 제공되는 대체 상태 지점에 문제를 보고합니다. 따라서 인터넷으로 관리되는 시스템과의 연결이 끊기지 않습니다. 또한 적절한 시기에 최적의 리소스를 효율적으로 사용할 수 있도록 클라이언트가 인터넷 기반 관리에서 인트라넷 기반 관리로 자동 로밍될 수 있습니다.

기타 새로운 기능
중요한 기능으로 보이지는 않지만, Wake-On-LAN은 관리자가 업무에 지장을 주지 않고 신속히 소프트웨어를 배포 또는 업데이트하거나 OS를 배포하는 데 매우 유용한 도구 중 하나입니다. Configuration Manager 2007에서는 호환되는 네트워크 카드가 있고 인트라넷에 기반을 둔 모든 관리되는 에이전트에 Wake-On-LAN 기능을 사용할 수 있습니다. 그림 8은 새롭게 설계된 New Advertisement Wizard의 Advertisement에 Wake-On-LAN을 어떻게 사용하는지를 보여 주는 예로, 컴퓨터 그룹에 새 패키지를 배포하는 과정을 나타냅니다. 마법사에서 이 설정을 사용하도록 지정했지만 Wake-On-LAN 호환 장치가 꺼져 있으면 Configuration Manager는 시스템을 시작하여 Advertisement 기능을 통해 정의된 패키지를 배포합니다.
그림 8 소프트웨어 배포 Advertisement의 Wake-On-LAN
그림 8 소프트웨어 배포 Advertisement의 Wake-On-LAN
훨씬 빠른 성능으로 보다 안전하고 안정적인 솔루션을 제공할 수 있도록 Configuration Manager에서는 원격 제어 기능이 완전히 새롭게 작성되었습니다. SMS 1.0부터 사용된 도구 대신, Configuration Manager에는 Windows Vista의 RDP(Remote Desktop Protocol)를 기반으로 한 기본 공동 작업 기술이 사용됩니다. 최종 사용자가 새로운 세션을 시작할 필요가 없다는 점에서 기본 기능은 SMS 2003과 같지만 모든 권한, 보기 전용 및 없음이라는 세 가지 권한 수준이 추가되었습니다. 이렇게 신기술이 추가되긴 했지만 원격 지원 기술이 필요한 경우를 대비해 이 기술도 Configuration Manager 2007에 통합되었습니다.

결론
지금까지 System Center Configuration Manager 2007에서 새로 추가되거나 향상된 기능 몇 가지를 살펴보았습니다. 이러한 기능은 관리 업무를 쉽게 하고 새로운 작업을 가능하게 하며 IT 환경의 비용을 절감하도록 도와 줍니다. System Center 제품군의 다른 제품과 마찬가지로 Configuration Manager 2007을 사용하면 비즈니스 경쟁력을 유지하면서 요구 사항이 많은 IT 인프라를 효과적으로 관리할 수 있습니다.
이 기사에서 설명한 기능 외에도 Windows Server® 2008 NAP(네트워크 액세스 보호) 기능 통합, SMS 2003 SP3에 포함된 Asset Intelligence 기술을 기반으로 하지만 보다 향상된 SAM(소프트웨어 자산 관리) 기능 등 여러 가지 측면에서 제품이 향상되었습니다. Configuration Manager 2007 릴리스 후보 버전이나 RTM 평가판을 다운로드하여 현재 인프라에서 이러한 기능을 어떻게 사용할 수 있는지 확인해 보시기 바랍니다.
System Center 제품군에 포함된 모든 제품에 대한 자세한 내용 및 개요는 microsoft.com/systemcenter를 참조하십시오. 이 웹 사이트에서 Configuration Manager를 비롯한 System Center 제품군의 모든 솔루션을 찾아볼 수 있습니다.

John Orefice는 Microsoft 중부 대서양 연안 지부에서 기술 솔루션 전문가로 근무하고 있으며 컨설턴트로 시작해 현재의 위치에 이르기까지 지난 몇 년 동안 MCS(Microsoft Consulting Services)에서 Microsoft 관리 솔루션을 담당하고 있습니다. 문의 사항이 있으면 john.orefice@microsoft.com으로 연락하십시오.
© 2007 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..


 System Center: 지사에 응용 프로그램 및 업데이트 배포
System Center Steve Rachui

지사에 응용 프로그램 및 업데이트 배포
한 눈에 보기:
  • 지사 배포 지점(BDP) 구성
  • 경계에 관한 모든 것
  • 데이터 프로비저닝의 세 가지 방법

Microsoft는 차세대 시스템 관리 솔루션 System Center Configuration Manager 2007을 곧 출시할 예정입니다. 이전의 Systems Management Server(SMS)를 새로 업그레이드한 이 제품에는
인상적인 새로운 기능들이 많이 들어 있습니다. 이 편리한 기능 중 하나가 지사 배포 지점(BDP)이라는 기능으로, 특히 소규모 또는 분산된 사무실 설정에 맞게 설계된 새로운 유형의 배포 지점입니다. 언뜻 다른 기능과 비교해 보면 이 BDP가 사소한 추가 기능으로 보일 수도 있지만 속단은 금물입니다.
이전의 SMS 버전에서는 배포 지점 호스팅에 지원되는 플랫폼이 서버 시스템뿐이었습니다. 이 때문에 로컬 서버가 부족하고 속도가 느린 WAN 링크를 이용하는 지사에 서비스를 제공해야 하는 관리자들은 필요한 시기에 효과적으로 소프트웨어를 배포할 수 있는 인프라를 설계하고 구축하기 위해 노력했습니다. 그리고 바로 이 문제를 해결하기 위해 BDP가 개발된 것입니다.
워크스테이션과 서버급 시스템에서 모두 작동하도록 설계된 BDP는 기본적으로 설정되어 있지는 않지만 모든 Configuration Manager 2007 클라이언트에서 사용할 수 있는 구성 요소입니다. 모든 Configuration Manager 2007 클라이언트에는 BDP로 작동하는 데 필요한 코드가 들어 있지만 모든 클라이언트가 이런 방식으로 구성되는 것은 아닙니다.

BDP 설정
클라이언트에서 BDP 기능을 활성화하는 방법은 기본적으로 모든 서버 기반 배포 지점을 구성하는 것과 같습니다. 먼저 클라이언트를 새로운 사이트 시스템(그림 1 참조)으로 구성한 다음 지사 배포 지점임을 표시합니다(그림 2 참조). 이렇게 구성하면 BDP가 패키지, 소프트웨어 업데이트, OSD(Operating System Deployment) 이미지 등에 사용할 수 있는 배포 지점으로 목록에 포함됩니다. 정책은 사이트 서버에 의해 준비되고 BDP 기능을 켜게 될 선택된 클라이언트의 대상으로 지정됩니다. 이 정책을 다운로드하고 나면 해당 클라이언트가 BDP로 작동하기 시작합니다.
그림 1 클라이언트를 새로운 사이트 시스템으로 구성
그림 1 클라이언트를 새로운 사이트 시스템으로 구성
그림 2 사이트 시스템을 지사 배포 지점(BDP)으로 구성
그림 2 사이트 시스템을 지사 배포 지점(BDP)으로 구성
BDP와 모든 사이트 시스템은 특정 경계(SMS 2003에서는 사이트 경계라 불림) 또는 경계 그룹에 서비스를 제공하도록 구성할 수도 있고 경계 제한 없이 작동하도록 구성할 수도 있습니다. Configuration Manager 2007의 경계는 주로 IP 서브넷이나 Active Directory® 사이트에 의해 정의됩니다.
BDP가 특정 경계 집합에 서비스를 제공하도록 구성하려면 사이트 시스템 구성 창에서 "Enable this site system as a protected site system(이 사이트 시스템을 보호되는 사이트 시스템으로 설정)" 옵션을 선택한 다음 그림 1과 같이 서비스 대상 경계를 지정하면 됩니다. BDP를 주문형 콘텐츠 프로비저닝(아래에 자세히 설명)에 사용할 계획이라면 이 단계를 반드시 수행해야 합니다. 이 단계를 수행하지 않으면 BDP는 일반 표준 배포 지점으로 작동합니다.

경계에 대하여
BDP에서 보호되는 경계는 BDP의 콘텐츠를 액세스할 수 있는 클라이언트를 지정하는 역할만 하며, BDP가 필요한 콘텐츠를 다운로드하기 위해 액세스할 수 있는 표준 배포 지점을 결정하는 역할은 하지 않습니다. 예를 들어 BDP가 경계 A에 설치된 환경이 있다고 가정해 봅시다. 그리고 경계 B에는 BITS(Background Intelligent Transfer Service)를 사용하는 표준 배포 지점만 있고 이 배포 지점은 경계 B의 클라이언트에만 서비스를 제공하도록 구성되었습니다. BDP가 콘텐츠 다운로드를 시도하면 성공할까요? 보호되는 경계의 예상된 규칙에 따르면 다운로드가 실패할 것이라 생각할 수 있습니다. 그러나 이 시나리오에서 다운로드는 성공하게 됩니다. BDP 다운로드가 표준 배포 지점에서 구성된 보호되는 경계를 하나도 인식하지 않기 때문입니다.
BDP는 유연성 또한 뛰어납니다. 지사당 한 개의 BDP를 설정할 수도 있고 필요에 따라 한 개의 지사(경계)에 여러 BDP를 설정할 수도 있습니다. 여러 BDP가 하나의 경계에 서비스를 제공하도록 구성된 경우, 이러한 BDP는 부하 분산처럼 작업을 나누어 해당 경계 내의 클라이언트에 콘텐츠를 제공합니다.

데이터 프로비저닝
일단 설정된 BDP는 관리자 프로비저닝, 주문형 프로비저닝, 수동 프로비저닝의 세 가지 방법으로 필요한 콘텐츠를 가져올 수 있습니다. 이 중 어떤 방법을 사용하여 콘텐츠를 가져오든 BITS가 설정되어 있으며 BDP가 받게 될 콘텐츠로 프로비저닝되는 표준 배포 지점이 한 개 이상 있어야 합니다. 그러면 콘텐츠를 가져오는 데 사용할 수 있는 이 세 가지 방법을 하나씩 자세히 살펴 보겠습니다.
관리자 프로비저닝 배포 지점에 콘텐츠를 준비하는 친숙한 방법입니다. 이 방법을 사용하려면 관리자가 직접 BDP를 배포 지점으로 선택해야 합니다. 그러면 BDP에게 다음 정책 업데이트 사이클 동안 동일한 사이트 내의 BITS 지원 표준 배포 지점에서 프로비저닝되는 콘텐츠를 다운로드하라고 알려주는 정책이 준비됩니다.
주문형 프로비저닝 콘텐츠를 준비하는 새로운 방법으로 BDP에만 적용됩니다. 이 방법을 사용하면 클라이언트가 요청할 때 필요에 따라 콘텐츠가 BDP에 다운로드됩니다. 이때 관리자는 BDP에 콘텐츠를 프로비저닝하기 위한 조치를 취하지 않습니다. 즉, BDP가 패키지 노드 내에서 배포 지점으로 선택되지 않는 것입니다. 주문형 프로비저닝을 사용하면 콘텐츠 요청이 발생할 때 BDP가 효과적으로 배포 지점으로 선택됩니다. 그리고 이러한 작업은 배경에서 자동으로 수행됩니다.
콘텐츠를 요청하는 클라이언트가 BDP만 액세스하고 콘텐츠가 들어 있는 표준 배포 지점에는 액세스할 수 없도록 하기 위해 주문형 프로비저닝은 패키지가 이 옵션을 지원하도록 구성되고(그림 3 참조) BDP가 보호되는 경우에만 사용할 수 있습니다. 보호되는 동일한 경계 내에 여러 BDP가 구성된 경우 한 개의 BDP에 주문형 프로비저닝 요청이 발생하면 콘텐츠가 모든 BDP에 프로비저닝됩니다.
그림 3 패키지의 주문형 배포 활성화
그림 3 패키지의 주문형 배포 활성화
수동 프로비저닝 이름에서도 알 수 있듯이 이 콘텐츠 준비 방법에서는 관리자가 직접 작업을 수행해야 합니다. 패키지는 그림 3과 같이 콘텐츠가 수동으로 전송된다는 것을 나타내도록 구성해야 합니다. 그런 다음 이 콘텐츠를 일반적인 패키지에서 예상되는 디렉터리 구조를 사용하여 BDP의 패키지 폴더로 직접 복사해야 합니다.
BDP는 이 새 패키지를 인식하고 요청 클라이언트에게 제공합니다. 이 방법을 사용하면 이동식 미디어를 통해 콘텐츠를 BDP에 전송할 수 있기 때문에 표준 배포 지점과 BDP 사이의 대역폭이 제한된 환경에서 최상의 방법이라 할 수 있습니다.
BDP가 다운로드된 콘텐츠를 특정 파티션에 저장하도록 구성할 수 있습니다. 지정된 파티션이 없으면 BDP는 사용할 파티션을 자동으로 선택합니다. 콘텐츠가 BDP에 준비되도록 구성되거나 주문형 요청이 처리되었다고 해서 대상 콘텐츠를 BDP에서 바로 이용할 수 있는 것은 아닙니다. BDP에게 콘텐츠를 다운로드할 수 있다고 알려주는 정책이 준비되어야 합니다. 다음 정책 사이클에서 BDP는 이 정책을 수신하고 콘텐츠의 BITS 다운로드를 시작합니다. 그룹 정책을 사용하면 사용되는 대역폭과 BITS 다운로드 일정을 정밀하게 제어할 수 있습니다. BDP의 배포 지점 공유는 표준 배포 지점의 공유와 똑같아 보입니다. 말하자면 콘텐츠가 암호화되지 않는 것입니다.

조직별로 알맞은 설정
앞서 언급했듯이 BDP 역할은 지사를 위해 고안되었고 워크스테이션 시스템에서도 완전하게 작동합니다. 그러나 BDP를 서버급 시스템에서 작동할 수도 있습니다. 기본 OS에 따라 BDP에 연결할 수 있는 수가 달라집니다. 워크스테이션에서는 동시 연결 수가 10개로 제한되는 반면 서버의 경우 이런 제한이 없습니다. 따라서 지원해야 할 동시 연결 수에 따라 서버 시스템을 사용하거나 지사 내 워크스테이션 시스템을 여러 대 사용해야 할 수 있습니다. 사용하는 플랫폼에 상관없이, 요청되는 콘텐츠가 있는 BITS 지원 표준 배포 지점이 한 개 이상 있어야 합니다.
인프라가 어떻게 구성되었는지에 관계없이 BDP는 조직 전체의 소프트웨어 배포 흐름을 훨씬 효과적으로 제어할 수 있게 해 줍니다. 또한 다운로드 조절 및 예약을 지원하는 BITS가 기본적으로 지원되기 때문에 보다 정밀한 제어와 예측 기능을 원하는 관리자에게 매우 유용합니다.

Steve Rachui는 Microsoft 기술 지원 서비스 그룹의 관리 효율성 지원 향상 엔지니어로, SMS 버전 1.2부터 SMS를 지원해 왔습니다. 문의 사항이 있으면 steverac@microsoft.com으로 연락하시면 됩니다.


 System Center: System Center Essentials 2007 시작
System Center David Mills

System Center Essentials 2007 시작
한 눈에 보기:
  • 설치 및 업그레이드
  • Essentials 2007 구성
  • 문제 해결 단계

System Center Essentials 2007(이하 Essential 2007)은 PC 50~500대, 서버 5~30대를 보유한 중소기업에 알맞게 설계된 새로운 IT 관리 솔루션입니다. Essentials 2007은 통합 관리 솔루션에 대한 IT 전문가들의 광범위한 의견과 요구 사항을
반영한 솔루션입니다. Essentials 2007을 사용하면 이러한 요구 사항을 해결할 수 있으며 한 번의 설치와 쉬운 구성으로 보다 신속하게 솔루션을 실행할 수 있습니다.
좀 더 세부적으로 살펴보면, Essentials 2007은 모니터링, 문제 해결 및 자산 추적 기능을 제공하여 IT 환경을 최신 상태로 안전하게 유지해 줍니다. 또한 Essentials 2007은 서버, 클라이언트, 하드웨어, 소프트웨어 및 IT 서비스를 관리할 수 통합 관리 콘솔입니다(그림 1 참조). 뿐만 아니라 최종 사용자 문제 해결, 모니터링, 서버 및 클라이언트 소프트웨어 배포와 같은 복잡한 관리 작업을 보다 쉽고 효율적으로 수행할 수 있습니다.
그림 1 Essentials 2007 관리 콘솔
그림 1 Essentials 2007 관리 콘솔

Essentials 2007 요구 사항
Essentials 2007 설치 및 구성을 시작하기 전에 시스템 사양이 최소 소프트웨어 및 하드웨어 요구 사항을 충족하는지 확인하시기 바랍니다. 서버 운영 체제는 Windows Server® 2003 SP1 또는 R2이거나 Windows® Small Business Server 2003 SP1 이상이어야 합니다. 또한 Active Directory®, IIS 6.0, Microsoft® .NET Framework 2.0 및 3.0 이상, SQL Server™ 2005 SP1이 필요합니다. 서버의 경우 최소 1GB RAM, 12GB의 사용 가능한 디스크 공간, 1.8GHz 프로세서를 갖추고 있어야 합니다. 컴퓨터의 경우 2GB RAM, 20GB의 사용 가능한 디스크 공간, 2.8GHz 이상의 프로세서를 갖춘 것이 좋습니다.
관리되는 클라이언트 컴퓨터는 Windows 2000 Professional SP4, Windows XP SP2 또는 Windows Vista®를 실행해야 합니다. x86 및 x64 운영 체제 모두 지원됩니다.
관리되는 서버 컴퓨터는 Windows 2000 Professional SP4 또는 이보다 최신 운영 체제를 실행해야 합니다. 역시 x86 및 x64 운영 체제 모두 지원됩니다. 많은 사용자들이 자신의 데스크톱 또는 랩톱 컴퓨터에서 IT 환경을 모니터링 및 관리하고자 할 것이므로 사용 중인 컴퓨터에서 Essentials 2007 콘솔 전용 설치를 실행하길 원할 것입니다. 설치를 시작하기 전에 컴퓨터가 Windows XP SP2, Windows Vista 또는 Windows Server 2003 SP1을 실행하는지 확인하십시오.
Essentials 2007 서버를 구성하려는 경우 업데이트 다운로드 및 보고 데이터베이스를 처리하는 데 필요한 디스크 공간을 충분히 확보해 두어야 합니다. 업데이트의 경우 업데이트 데이터베이스 용량은 2GB, 업데이트 콘텐츠는 6GB를 초과할 수 있습니다. Essentials 작업 및 보고 데이터베이스는 4GB까지 확장될 수 있습니다. 따라서 이에 따라 저장 공간을 초과하지 않도록 계획을 세워야 합니다.

Essentials 2007 설치
Essentials 2007는 설치 마법사를 통해 설치 및 구성, 컴퓨터 검색, 업데이트 구성과 같은 중요한 작업을 신속하게 처리할 수 있으므로 설치가 매우 간단합니다. 설치 마법사를 실행하면 Essentials 2007에서 자동으로 필수 구성 요소를 확인하여 누락된 요소가 있을 경우 알려줍니다(그림 2 참조).
그림 2 설치 필수 구성 요소 확인
그림 2 설치 필수 구성 요소 확인
Essentials 2007 디스크에 필수 항목이 없는 경우 설치 화면에 해당 소프트웨어를 설치할 수 있는 링크가 표시됩니다. 설치 마법사를 실행하고 설치 과정이 진행되면 Essentials 2007을 설치할 위치 및 관리 권한 계정에 대한 정보를 입력해야 합니다. 해당 계정이 관리 서버 및 관리되는 컴퓨터 전체에 대한 관리자 권한을 가진 경우 Essentials 2007을 사용하여 컴퓨터 관리 작업을 대폭 간소화할 수 있습니다. Essentials는 관리되는 컴퓨터에 에이전트를 설치하는 작업 등을 수행하는 데 단일 계정을 사용할 수 있도록 지원합니다.
현재 SQL Server 2005가 설치되어 있지 않아서 로컬이든 원격이든 Essentials 2007에 SQL Server 2005를 사용할 수 없는 경우, 설치 중에 로컬에서 Advanced Services(고급 서비스)를 사용하여 Essentials 2007이 SQL Server 2005 Express를 설치하도록 선택할 수 있습니다. Essentials 2007 디스크에는 SQL Server Express 버전이 포함되어 있습니다. 또한 Essentials 2007에 사용할 수 있도록 라이선스를 받은 SQL Server 2005 Standard가 포함된 Essentials 2007 버전도 구입할 수 있습니다.
그밖에 Essentials 2007 설치 중에 결정해야 할 중요한 사항이 있다면 업데이트를 저장할 위치를 선택하는 것뿐입니다. 업데이트는 로컬로 저장한 다음 네트워크를 통해 Essentials 2007 서버에서 관리되는 컴퓨터로 전달할 수 있습니다. 특히 네트워크에서 인터넷 액세스 병목 현상이 자주 발생하는 경우 이 방법을 사용하는 것이 좋습니다. 컴퓨터를 업데이트해야 할 때마다 Microsoft Update에서 직접 업데이트를 다운로드할 수도 있습니다. 이 옵션을 선택하면 50대의 컴퓨터를 한 번 업데이트할 경우 각 컴퓨터마다 한 번씩 50번의 다운로드가 수행됩니다. 다소 귀찮은 과정일 수도 있지만, 이렇게 하면 관리 서버의 디스크 공간을 적게 사용할 수 있는 이점이 있습니다.
Essentials 2007에서 지원하는 기본 배포 토폴로지는 모든 관리 구성 요소를 단일 서버에 설치하는 것입니다(그림 3 참조). 그러나 Essentials 2007 관리 콘솔을 사무실의 데스크톱 또는 랩톱 컴퓨터에 설치한 후 관리 서버를 원격으로 제어할 수도 있습니다. 원격 콘솔을 설치하기 전에 반드시 Essentials 2007 서버의 Feature Configuration Wizard(기능 구성 마법사)를 실행해야 합니다. 이 프로세스는 원격 콘솔을 구성하는 데 도메인 그룹 정책을 사용할지, 로컬 그룹 정책을 사용할지 결정합니다. 도메인 그룹 정책을 선택한 경우 원격 콘솔을 설치할 컴퓨터에서 업데이트를 완료할 수 있을 만큼 충분한 시간이 지났는지 확인해야 합니다. 필요한 경우 원격 콘솔을 여러 개 설치할 수 있습니다.
그림 3 Essentials 2007 기본 구성
그림 3 Essentials 2007 기본 구성
200대 이상의 컴퓨터가 있는 IT 환경을 관리하는 경우 Essentials 2007 관리 서버가 아닌 원격 서버에 SQL Server 2005를 설치한 후 이 원격 인스턴스를 Essentials 2007 데이터베이스로 사용해야 합니다(그림 4 참조). 이렇게 하면 확장 시 성능을 개선할 수 있습니다. 이 원격 서버는 Essentials 2007 관리 서버와 같은 도메인에 있어야 합니다.
그림 4 원격 SQL Server 데이터베이스 사용
그림 4 원격 SQL Server 데이터베이스 사용
Essentials 2007 설치 시 기존 SQL 데이터베이스 인스턴스 사용을 선택한 경우, Essentials 2007 관리 서버에 SQL Server 2005 SP1 Reporting Services가 설치 및 구성되어 있어야 합니다.

Essentials 2007로 업그레이드
이미 WSUS(Windows Server Update Services) 2.0 또는 3.0을 실행하여 Microsoft 업데이트를 처리하고 있는 경우가 많을 것입니다. 이때 보다 광범위한 관리 솔루션을 위해 Essentials 2007로 업그레이드하고자 한다면 설치 프로세스 중에 업그레이드를 수행할 수 있습니다. 이러한 내부 업그레이드를 실행할 경우 바이너리, 그룹 및 승인과 같은 기존 업데이트 정보는 그대로 보존됩니다.
현재 MOM(Microsoft Operations Manager) 2005 또는 MOM 2005 Workgroup Edition을 사용하여 중요 서버를 모니터링하고 있지만 자산 인벤토리, 소프트웨어 배포 및 업데이트를 위해 Essentials 2007의 추가 기능을 활용하길 원하는 경우, 관리 팩을 내보내 변환한 다음 직접 Essentials 2007로 가져와 쉽게 마이그레이션할 수 있습니다. MOM 2005와 마찬가지로 Essentials 2007도 컴퓨터 및 장치를 모니터링하는 데 관리 팩을 사용합니다. 관리 팩에는 IT 문제를 올바르게 진단하고 이를 성공적으로 해결할 수 있는 정보도 포함되어 있습니다. Essentials 2007로 완전히 마이그레이션하지 않을 경우, 중요한 모니터링 작업은 그대로 수행하면서 필요에 따라 마이그레이션을 수행할 수 있습니다.
Essentials 2007로 업그레이드하는 과정에서 일부 WSUS 설정이 보존되지 않을 수 있으므로 주의해야 합니다. 컴퓨터, 자동 인증 및 설정, All Clients 또는 All Servers로 명명한 그룹에 대한 기존 승인 정보는 보존되지 않습니다. 그러므로 업그레이드를 수행하기 전에 WSUS에서 All Clients 및 All Servers 그룹을 삭제해야 합니다. Essentials 2007 설치를 모두 완료한 후에는 이러한 승인을 다시 만들어야 합니다
기존 서버에 사용 중인 다운스트림 서버가 있는 경우 WSUS에서 이 업그레이드 작업을 수행할 수 없습니다. Essentials 2007은 WSUS USS(업스트림 서버) 모드를 지원하지 않습니다. 이는 완벽하게 감지되지 않기 때문에 WSUS 서버에 다운스트림 서버가 있는 경우 경고 메시지가 표시됩니다. 또한 WSUS 데이터를 저장하는 데 SQL Server 2005 SP1을 사용하지 않는 원격 데이터베이스 서버에 WSUS 2.0 또는 2.0 SP1을 사용하는 경우 업그레이드를 진행하지 마십시오.
업그레이드 프로세스를 진행하면 현재 데이터베이스의 백업 복사본이 자동으로 생성됩니다. 업그레이드가 실패한 경우 백업 복사본을 사용하여 이전 환경을 복원할 수 있습니다. 현재 데이터베이스 파일 크기 및 복사본을 만들 공간을 확인하여 현재 WSUS 데이터베이스를 백업할 수 있는 충분한 공간을 확보해 두십시오.

Essentials 2007 구성
Essentials 2007에는 구성 및 관리 작업에 도움이 되는 여러 가지 마법사가 있습니다. Feature Configuration Wizard(기능 구성 마법사)를 사용하면 그룹 정책 구성과 같이 수동으로 작업하기 어려운 일부 구성 단계를 신속하게 처리할 수 있습니다. 그림 5는 마법사의 첫 번째 페이지입니다.
그림 5 Feature Configuration Wizard(기능 구성 마법사) 시작
그림 5 Feature Configuration Wizard(기능 구성 마법사) 시작
인터넷에 연결할 때 프록시 서버를 사용하는 경우 가장 먼저 수행하는 단계는 서버 이름 및 포트 번호를 입력하는 것입니다. 그 다음, 관리되는 컴퓨터를 구성할 그룹 정책 유형을 로컬 그룹 정책으로 할지 도메인 그룹 정책으로 할지 선택합니다. 도메인 그룹 정책을 사용하여 관리되는 컴퓨터를 구성하기로 선택한 경우 Windows 방화벽 예외를 생성할 수도 있습니다.
그 다음 단계는 선택 사항으로, 컴퓨터의 원격 지원 여부를 결정합니다. 도메인 그룹 정책을 사용하여 클라이언트를 구성하기로 선택한 경우 이 단계가 적용됩니다. 이 단계를 선택하면 관리되는 모든 컴퓨터에 방화벽 예외가 생성되어 TCP 포트 135를 통해 DCOM을 사용할 수 있습니다.
관리되는 컴퓨터에서 Agentless Error Monitoring(에이전트 없는 오류 모니터링)을 수집할지 여부를 선택할 수 있습니다. Yes(예)를 선택하고 오류 저장 위치를 지정하면 관리되는 컴퓨터에서 Essentials 2007 서버로 오류 보고서를 보냅니다. 그러면 사용자는 보고서를 보고 어떤 응용 프로그램에 문제가 있는지 확인할 수 있습니다.
오류 보고서를 Microsoft로 전달할 것인지, 경고, 업데이트, 소프트웨어 및 인벤토리 정보가 포함된 Daily Health Report(일일 상태 보고서)를 구성하여 보낼 것인지 지정하는 옵션이 있습니다. Daily Health Report(일일 상태 보고서)가 전자 메일로 전송되도록 구성해 놓으면 하루 업무를 시작하면서 IT 환경의 상태를 신속하게 파악할 수 있습니다.
마지막으로, 매일 새 컴퓨터 검색 작업을 수행하도록 예약할 수 있습니다. 이 옵션을 선택하면 Essentials 2007에서 매일 Active Directory를 검사하여 새 컴퓨터가 있는지 확인한 후 이러한 컴퓨터가 자동으로 관리되도록 구성하므로 이 옵션을 사용하는 것이 좋습니다.
자동 컴퓨터 검색을 위해 구성된 Computer and Device Management Wizard(컴퓨터 및 장치 관리 마법사)를 실행하면 Active Directory를 쿼리하여 도메인에서 관리되는 모든 컴퓨터를 검색하라는 명령이 Essentials 2007 서버로 전달됩니다(그림 6 참조). Advanced(고급) 검색 옵션을 선택하면 검색된 장치를 클라이언트나 네트워크 장치별로 필터링하거나 IP 주소 범위 내에서 검색하거나 고급 쿼리를 만들 수 있습니다. Automatic(자동) 컴퓨터 검색을 선택하고 이를 먼저 실행하여 모든 클라이언트와 서버를 검색하는 것이 좋습니다. 또한 Essentials 2007에서는 SNMP(단순 네트워크 관리 프로토콜)를 사용하는 네트워크 장치를 모니터링하므로 고급 모드에서 마법사를 다시 실행하여 네트워크 장치를 검색할 수 있습니다.
그림 6 Computer and Device Management Wizard(컴퓨터 및 장치 관리 마법사) 시작
그림 6 Computer and Device Management Wizard(컴퓨터 및 장치 관리 마법사) 시작
네트워크가 약 300대 이상의 컴퓨터로 구성된 경우 컴퓨터를 검색하려면 Advanced(고급) 검색을 통해 보다 세부적인 조건을 지정해야 합니다. 관리자 계정을 지정할 때는 계정이 검색 대상 컴퓨터 및 에이전트를 설치할 컴퓨터에 대한 관리 권한을 갖고 있는지 확인하십시오. 검색을 완료하면 관리할 컴퓨터를 선택하고 Finish(마침)를 누릅니다.
WSUS를 계속 사용해 왔다면 Update Management Configuration Wizard(업데이트 관리 구성 마법사)의 일부 설정에 익숙할 것입니다. 서버를 인터넷에 연결할 때 프록시 서버가 필요한 경우 프록시 서버 설정을 입력합니다. 업데이트를 다운로드해서 배포할 제품을 선택한 다음 업데이트에 필요한 언어를 선택합니다. 기본 언어는 서버의 언어입니다. 다운로드해서 배포할 업데이트의 범주를 선택합니다. Critical Updates(중요 업데이트), Security Updates(보안 업데이트) 및 Service Packs(서비스 팩)이 기본값입니다. 자동으로 승인할 업데이트 범주와 그룹을 선택합니다. All Computers 그룹의 Critical Updates(중요 업데이트) 및 Security Updates(보안 업데이트)가 기본값입니다. 마지막으로, 업데이트 동기화 일정을 설정합니다. 기본값은 하루입니다.
Essentials 2007 구성 시 도메인 관리자 또는 그룹 정책 관리자 자격 증명으로 로그온할 수 있는 경우, 관리되는 컴퓨터를 구성하려면 도메인 그룹 정책을 선택해야 구성 작업이 훨씬 간편해집니다. 도메인 그룹 정책을 선택하면 관리되는 모든 컴퓨터에서 Windows 방화벽 및 원격 지원 설정을 자동으로 구성할 수 있습니다. 이 옵션을 선택하면 Essentials 2007에서 자동으로 정책 구성을 만듭니다. 로컬 정책을 선택하면 상당한 부분을 수동으로 구성해야 합니다.

Essentials 문제 해결
컴퓨터 검색, 에이전트 배포 및 통신 문제를 해결할 때 몇 가지 고려해야 할 사항이 있습니다. 먼저, 컴퓨터 검색 프로세스가 어떻게 이루어지는지 간략하게 살펴보겠습니다. Essentials 2007은 사용자가 입력한 검색 내용 매개 변수를 사용하여 LDAP(Lightweight Directory Access Protocol) 쿼리를 만듭니다. LDAP는 Active Directory의 개체를 검색하는 데 사용되는 쿼리 언어입니다. 그러면 LDAP 쿼리가 로컬 도메인 컨트롤러로 전달되어 검색 작업을 제출하고 Active Directory는 관리 서버에 결과를 반환합니다. 그런 다음 관리 서버가 목록으로 반환된 각 컴퓨터와 연결되고 검색된 컴퓨터와 통신이 이루어지면서 관리 에이전트를 설치할 수 있게 됩니다. 확인된 컴퓨터는 추후 관리 작업 시 참조할 수 있도록 검색된 컴퓨터 목록에 추가됩니다.
그러나 Active Directory, 네트워크 및 DNS 또는 인증 문제가 발생한 경우 Essentials 2007 서버에서 컴퓨터 검색 작업을 수행하지 못할 수도 있습니다.
Active Directory Users and Computers 관리 콘솔을 열고 컴퓨터 목록이 있는지 확인합니다. 이 도구는 Windows Server 2003에 기본으로 설치되며 Windows Server 2003 Administration 팩을 통해 Windows XP Professional에 설치할 수 있습니다. Saved Queries(저장된 쿼리) 폴더를 선택하고 마우스 오른쪽 단추로 클릭한 다음 New(새로 만들기)를 가리키고 Query(쿼리)를 클릭합니다. 쿼리 이름을 입력한 다음 Define Query(쿼리 정의) 단추를 클릭합니다. Find(찾기)로 표시된 드롭다운 목록을 클릭하고 Computers(컴퓨터)를 선택합니다. 이름을 입력하거나 접두사를 검색한 다음 확인을 몇 번 클릭하여 쿼리를 만듭니다.
이제 결과 목록에 컴퓨터가 나타나는지 확인합니다. 컴퓨터가 나타나지 않을 경우 Active Directory에 컴퓨터를 추가합니다. 컴퓨터의 DNSHostname 속성을 올바르게 입력해야 합니다. 이 속성은 Active Directory Users and Computers 관리 콘솔에서 컴퓨터 속성 대화 상자의 General(일반) 탭에서 확인할 수 있습니다.
네트워크를 통해 컴퓨터에 연결해야 하는 경우 ping 명령을 사용하여 검색 마법사에 입력한 이름과 동일한 이름을 사용하는 컴퓨터를 액세스합니다. 컴퓨터가 ping 명령에 응답하면 -a 스위치와 IP 주소를 지정하고 ping을 실행합니다.
ping -a <IP address>
다음 명령은 컴퓨터의 DNS를 표시하는 것으로, 원본 ping 명령에 사용된 것과 일치해야 합니다. 이 명령을 사용하여 컴퓨터에 등록된 NetBIOS 이름 및 도메인을 확인합니다.
nbtstat -a <computer name>
이는 컴퓨터의 IP 주소에 대해서도 같은 작업을 수행합니다.
nbtstat -A <IP address>
명령 스위치 -a는 대/소문자를 구분합니다. IP 주소를 사용할 때는 -A를 사용하십시오. 컴퓨터가 ping 요청에 응답하지 않거나 "RPC Service Unavailable(RPC 서비스를 사용할 수 없음)"이라는 메시지와 함께 원격 에이전트 설치에 실패할 경우 Windows 방화벽이 켜져 있는 것입니다. Essentials 2007 배포 환경에서 방화벽이 활성화된 경우 예외를 만들어야 Essentials 2007 관리 서버가 관리되는 컴퓨터에 에이전트를 성공적으로 설치할 수 있고 관리되는 컴퓨터가 관리 서버와 통신할 수 있습니다. 관리되는 컴퓨터를 사용할 때 로컬 그룹 정책이 아닌 도메인 그룹 정책을 사용하는 경우 수동으로 방화벽 예외를 만들지 않아도 됩니다.
에이전트 설치가 실패한 경우 Administration(관리) 영역(Reporting(보고) 이동 단추 옆에 있는 기본 Essentials 2007 관리 콘솔의 왼쪽 아래 금색 부분)으로 이동하여 Pending Management(보류 관리)를 클릭합니다. 이 보기에는 문제 해결 단계와 처음 설치에 실패한 에이전트를 컴퓨터에 다시 설치하는 방법이 표시됩니다.
관리해야 할 모든 컴퓨터에 방화벽 정책을 적용하는 데에는 여러 시간이 소요됩니다. Feature Configuration Wizard(기능 구성 마법사)를 실행하고 도메인 그룹 정책 및 Computer and Device Management Wizard(컴퓨터 및 장치 관리 마법사)를 연속으로 빠르게 선택하려고 하면 검색하고 있는 컴퓨터에 방화벽 정책이 제대로 적용되지 못해 방화벽을 계속 사용하고 있는 경우 검색 작업이 실패할 수 있습니다.
에이전트가 컴퓨터에 성공적으로 설치되었는지 확인할 수 있는 한 가지 방법은 관리 서버에서 해당 컴퓨터로 텔넷 연결을 시도하는 것입니다. 포트 135를 통해 관리 서버에서 해당 컴퓨터로 텔넷 연결을 할 수 있으면 에이전트가 제대로 설치된 것입니다. 텔넷 연결을 할 수 없는 경우 컴퓨터의 방화벽이 TCP 포트 135를 차단한 것일 수 있습니다. 텔넷을 실행하려면 명령 창을 실행하고 다음을 입력합니다.
telnet <computer_name> 135
이렇게 하면 포트 135를 통해 지정된 컴퓨터 이름에 텔넷으로 연결할 수 있습니다. 포트 135는 에이전트를 원격으로 설치할 때 사용되므로 매우 중요한 포트입니다.
이 방법으로 문제가 해결되지 않는 경우 에이전트 배포 및 관리 서버와의 통신을 허용하는 적절한 Windows 방화벽 예외가 만들어졌는지 확인합니다. 예외가 만들어지지 않은 경우 그림 7에 나타난 것과 같이 포트 예외를 만들어야 합니다. 모든 예외의 경우 Custom(사용자 지정) 목록 옵션을 사용하여 Essentials 2007 관리 서버의 IP 주소 범위를 제한하십시오.
Figure 7 포트 예외 (Close Figure 7)

프로토콜 | 이름 | 포트
TCP | Port 6270 | 6270
TCP | Port 135 | 135
TCP | Port 445 | 445
컴퓨터에서 기타 제조업체의 방화벽 소프트웨어를 사용하고 있는 경우 해당 제품 설명서에 명시된 예외 생성 방법을 참조해야 합니다. 그러나 그림 7에 나열된 포트 예외는 그대로 적용해야 합니다.
NetBIOS 이름과 FQDN(정규화된 도메인 이름)이 일치하지 않는 경우 컴퓨터의 DNS 기록을 올바르게 수정해야 합니다. 에이전트를 설치했지만 관리 서버에 연결할 수 없는 경우 터미널 서비스 또는 원격 데스크톱을 통해 에이전트 컴퓨터에 연결한 다음 ping 및 nbtstat 명령을 사용하여 해당 에이전트가 관리 서버의 NetBIOS 및 FQDN 이름을 확인할 수 있는지 확인합니다.
Essentials 2007 관리 서버의 IP 주소가 동적으로 할당되는 경우 IP 주소가 변경되면 관리되는 컴퓨터의 방화벽 정책도 업데이트해야 합니다. 관리 서버의 새 IP 주소에 맞게 방화벽 예외를 업데이트하려면 그룹 정책 개체 편집기에 다음 두 가지 정책을 설정하고 아래 설명에 따라 정책을 구성합니다. "Windows 방화벽: 원격 관리 예외 허용"의 경우, 관리 서버의 새 IP 주소에서 들어오는 요청되지 않은 수신 메시지를 허용하도록 설정합니다. "Windows 방화벽: 파일 및 프린터 공유 예외 허용"의 경우, 관리 서버의 새 IP 주소에서 들어오는 요청되지 않은 수신 메시지를 허용하도록 설정합니다.

요약
이 문서에 설명된 내용이 System Center Essentials 2007을 처음 접하는 사용자에게 유용한 길잡이가 되기를 바랍니다. 새 System Center 제품에 대한 자세한 내용은 microsoft.com/sce를 참조하시기 바랍니다.
배포 전에 세심한 계획을 세우는 것만큼 중요한 일은 없다는 사실을 명심하시기 바랍니다. 이 경우 완전히 새로운 솔루션을 배포하여 IT 환경을 관리하게 되므로 현재 네트워크 구성, 사용자의 작업 방식, IT 자원을 관리할 방법 등을 충분한 시간을 들여 고려해야 합니다. 이러한 사항을 먼저 살펴보아야 Essentials 2007을 목적에 맞게 성공적으로 구성할 수 있습니다.

David Mills는 Microsoft에서 7년간 일해 왔으며 현재 System Center Essentials 2007 기술 제품 수석 관리자를 맡고 있습니다. System Center 마케팅 팀에 합류하기 전에는 Windows Server 부서의 사용자 지원 팀에서 핵심 네트워킹 및 관리 기술에 관한 IT 전문 기술 문서 제공 업무를 담당했습니다.


 System Center: 탁월한 서버 모니터링 기능을 제공하는 Operations Manager 2007
System Center Pete Zerger

탁월한 서버 모니터링 기능을 제공하는 Operations Manager 2007
한 눈에 보기:
  • Operations Manager 2007의 새로운 기능
  • 운영 콘솔 사용 방법
  • 역할의 역할
  • 새롭고 강력한 보고 기능

System Center Operations Manager 2007은 Microsoft 운영 관리 플랫폼의 수준을 한 단계 끌어올린 제품으로, 컴퓨터 중심의 모니터링에서 진정한 서비스 지향적 모니터링 플랫폼으로 전략적 패러다임의 변화를 잘 보여줍니다.
Microsoft® Operations Manager (MOM) 2005 관리자에게 친숙한 개념을 더욱 발전시킨 이 새로운 모델은 에이전트 기반 모니터링 솔루션으로서 이전 버전과 일부 유사한 점도 있지만 많은 부분이 변경되었습니다. 앞으로 살펴보겠지만, Microsoft System Center 제품군에 최근 추가된 이 새로운 버전과 관련하여 살펴볼 만한 흥미로운 새 기능과 새로운 관리 인터페이스, 그리고 추가 리소스가 많습니다.

관리 인터페이스
변화가 가장 뚜렷이 드러나는 부분은 새로운 관리 인터페이스입니다. 운영 콘솔과 관리자 콘솔이 더 이상 구분되지 않는 대신, 통합된 운영 콘솔을 통해 관리, 저작, 운영, 보고 기능(그림 1 참조)이 제공됩니다. 자주 혼란을 야기했던 MOM 2005 관리자 콘솔의 단일 폴더 트리도 사라졌습니다. Outlook®과 매우 유사한 인터페이스가 그 자리를 대신하여 모니터링, 제작, 보고, 관리, 내 작업 영역 등의 5가지 기능별 작업 영역을 제공합니다.
그림 1 운영 콘솔
그림 1 운영 콘솔
모니터링 작업 영역에는 MOM 2005의 운영자 콘솔에서 볼 수 있는 것과 유사한 깔끔한 인터페이스로 네트워크 인프라의 알림, 상태, 성능 및 다이어그램 보기가 표시됩니다.
제작 작업 영역은 새로운 규칙을 만들고 규칙과 모니터 기능이 작동할 그룹을 구성하는 데 사용됩니다. 운영 콘솔에는 획기적으로 개선된 보고 인터페이스가 통합되어 별도의 보고 웹 사이트를 사용할 필요가 없습니다. 컴퓨터 및 네트워크 장치 검색과 보안 및 알림 설정 구성 등 관리 작업 실행을 위한 인터페이스도 포함되었습니다. 마지막으로 내 작업 영역에서는 사용자 지정 보기를 만들고, 자주 사용하는 보기와 검색을 저장하고, 사용자 지정 알림 구독 기능을 구성할 수 있습니다.
운영 콘솔은 개념 안내, 온라인 웹캐스트, 제품 설명서 등의 링크를 비롯하여 상황에 맞는 도움말 기능을 갖추고 있습니다. 또한 풍부한 검색 기능을 갖추고 있어, 사용자들이 고급 검색 기준을 정의하여 어떤 유형의 개체든 검색할 수 있으며 검색 시 정의한 개체 유형과 값 특성에 따라 결과를 반환합니다.
운영 콘솔의 작업 창은 개체 구성 및 상태에 대한 정보를 얻을 수 있는 상황에 맞는 작업을 다수 제공하며, 대상 개체에 대해 새로운 상태 탐색기를 실행할 수 있습니다(그림 2 참조). 상태 탐색기에서 특정 항목(모니터링되는 개체)의 상태를 나타내는 트리 구조는 계층 구조로 되어 있습니다. 모든 엔터티는 최소한 4개의 매개 변수, 즉 가용성, 구성, 성능, 보안을 기준으로 모니터링됩니다. 이 값들은 단계적으로 상승합니다. 이 매개 변수들 각각의 상태는 계층 구조에서 그 아래 속해 있는 모니터의 상태에 근거하여 계산됩니다.
그림 2 상태 탐색기
그림 2 상태 탐색기
상태 탐색기는 모니터링 대상 개체의 장애를 진단하고 이벤트 세부 정보에 포함된 하이퍼링크를 클릭하여 오류 상황에 대해 조치를 취할 수 있는 기능을 제공합니다. 상태 탐색기의 세부 정보 창에 나타나는 진단 또는 복구 작업(그림 3 참조)을 필요에 따라 실행하거나, 경고가 생성되었을 때 작업이 자동으로 실행되도록 구성할 수 있습니다. 상태 변경 이벤트를 선택하면 실행 중인 프로세스 목록 검색 등과 같은 진단 작업 결과가 세부 정보 창에 자동으로 표시됩니다.
그림 3 진단 및 복구
그림 3 진단 및 복구

웹 콘솔
이 릴리스에서는 Operations Manager의 웹 기반 관리 기능이 크게 확대되었습니다. 웹 콘솔은 운영 콘솔의 모니터링 및 내 작업 영역 기능을 Internet Explorer®를 통해 표시함으로써, 상황에 맞는 작업을 실행할 수 있는 완전한 기능의 작업 창, 모니터링 대상 개체를 유지 관리 모드로 전환하는 기능 등 운영 콘솔과 동일한 기능을 갖춘 보기를 제공합니다(그림 4 참조).
그림 4 웹 콘솔
그림 4 웹 콘솔
모든 웹 지원 모바일 장치에서 액세스할 수 있는 모바일 웹 콘솔도 포함되었습니다. 웹 콘솔은 Outlook 2007 받은 편지함 또는 사용자가 선택한 RSS 리더에 경고 메시지를 전달하는 RSS 피드를 제공합니다.

명령 셸
Operations Manager 명령 셸은 명령줄을 통해 모든 관리 기능을 제어할 수 있는 강력한 인터페이스입니다. 여러 복잡한 작업들을 단 한 줄의 코드(일명 one-liner)로 시작할 수 있습니다. 명령 셸은 Microsoft .NET Framework 기반의 개체 지향 명령줄 환경인 Windows PowerShell™을 특별히 구성한 인스턴스로, 운영 콘솔 GUI에서 제공하는 모든 작업을 실행할 수 있는 cmdlet라는 함수를 다수 이용할 수 있게 해주며 그 외에도 다양한 기능을 제공합니다. cmdlet를 사용하면 많은 수의 에이전트를 유지 관리 모드로 설정하는 작업과 같이 다수의 개체를 대상으로 하는 작업을 운영 콘솔보다 쉽고 빠르게 실행할 수 있습니다. 예를 들어 열려 있는 모든 중요 경고 메시지의 목록을 웹 페이지로 내보내려면 Operations Manager 명령 셸 창에서 다음과 같은 명령을 실행합니다.
get-alert | where {$_.Severity -gt "Warning" -and $_.ResolutionState -eq 0 } | format-table
monitoringobjectdisplayname,name,severity,
description
명령 셸이 이처럼 강력한 기능을 발휘하는 이유는 Windows PowerShell이 그 특성상 객체 지향적이기 때문입니다. 따라서 C# 또는 Visual Basic® .NET을 몰라도 Operations Manager .NET 클래스 라이브러리의 강력한 기능을 활용할 수 있는 것입니다.

컴퓨터 및 장치 검색
Operations Manager의 컴퓨터 검색 및 에이전트 배포 기능도 역시 향상되었습니다. 운영 콘솔에서 컴퓨터 및 장치 관리 마법사를 이용하여 에이전트를 검색할 수 있으며, 관리자는 Active Directory®를 검색하거나 대상 컴퓨터 또는 컴퓨터 목록을 직접 입력할 수 있습니다(그림 5 참조). 상세한 LDAP(Lightweight Directory Access Protocol) 쿼리 기능을 이용하면 좀 더 구체적으로 특정 컴퓨터를 대상으로 에이전트를 설치할 수 있습니다.
그림 5 Active Directory 쿼리를 통한 고급 검색
그림 5 Active Directory 쿼리를 통한 고급 검색
컴퓨터 및 장치 관리 마법사를 이용하면 SNMP(단순 네트워크 관리 프로토콜) 지원 장치를 검색하여 관리 팩 규칙에서 모니터링 대상으로 설정할 수 있습니다.
Active Directory와의 통합 기능도 중요한 기능 향상 항목 중 하나입니다. 간단한 유틸리티를 통해 Active Directory에 관리 그룹 정보를 등록할 수 있게 해주므로 Operations Manager 에이전트는 시작할 때 Active Directory에 쿼리하여 적절한 관리 서버의 위치를 찾을 수 있습니다. 또한 이 새로운 통합 기능으로 인해 관리자가 컴퓨터 이미지에 Operations Manager 에이전트를 추가하거나, Systems Management Server 2003 또는 System Center Configuration Manager와 같이 널리 사용되는 시스템 관리 플랫폼을 통해 에이전트를 설치하거나, 그룹 정책을 통해 에이전트 설치 작업을 자동화, 간소화할 수 있습니다.

보안
Operations Manager 2007은 다양한 종류의 응용 프로그램 모니터링에 사용할 수 있는데, 그 가운데 일부는 특정한 지원 담당자만 이용할 수 있도록 제한해야 합니다. 다행히 새로운 역할 기반 보안 모델에는 읽기만 가능한 운영자에서 관리자까지, 일반적인 직무에 따라 그룹 액세스가 가능한 5가지 기본 사용자 프로필이 있습니다. 각 기본 사용자 역할은 이러한 기본 프로필을 기반으로 합니다. 사용자 역할은 특정 사용자가 수행할 수 있는 작업의 유형과 그 권한 범위를 정의합니다. 또한 기본 프로필 중 하나를 선택하고 그 프로필로 모니터링해서 볼 수 있는 데이터를 특정한 개체, 작업, 보기 등으로 제한하여 역할 범위를 설정함으로써 역할을 사용자 지정할 수 있습니다. 이러한 사용자 프로필을 기반으로 한 표준 및 사용자 지정 사용자 역할을 Active Directory 보안 그룹에 할당하면 사용자 프로비저닝 작업을 보안 관리 담당자가 실행하도록 할 수 있습니다.
역시 Operations Manager 2007에 새로 추가된 Run As Execution 기능은 특정 작업의 수행에 필요한 자격 증명 관리를 위한 안전한 인프라를 제공합니다. 예를 들어 일부 모니터링 작업에는 높은 권한을 가진 자격 증명이나 심지어 Windows 기반이 아닌 자격 증명이 필요할 수 있습니다.
Run As Accounts는 반드시 Run As Profile과 연결되어야 하며, 이 프로필은 특별한 권한을 요구하는 규칙 또는 작업과 연결될 수 있습니다. Run As Profile을 이용하면 Operations Manager에 관리 팩이 설치된 후 적절한 Run As 계정을 연결할 수 있도록 관리 팩 작성자가 작성 과정 중 계정 요구 사항을 추상화할 수 있습니다.
Operations Manager 2007은 에이전트와 관리 서버 사이의 통신 과정에서 상호 인증을 요구함으로써 이전 버전보다 보안을 강화했습니다. 트러스트 관계가 설정된 환경에서는 Kerberos를 통해 상호 인증을 처리할 수 있습니다. 트러스트 관계가 없는 경계 네트워크 환경에서는 상황이 더 복잡해질 수 있습니다. 상호 인증에는 x.509 인증서를 사용하는 인증서 기반 권한 부여가 필요하며 이를 위해서는 아직 이를 적용하지 않은 조직의 경우 PKI(공개 키 인프라) 옵션에 대해 고려해야 하기 때문입니다.

서버 역할
MOM 2005의 관리 서버, 운영 데이터베이스, 보고 서버 역할이 Operations Manager에서도 계속 지원되는 한편, 새로운 관리 서버 역할도 도입되었습니다. 루트 관리 서버 역할은 사용자 권한 부여, 알림 및 콘솔 연결 관리와 같은 핵심 기능을 인프라의 전용 역할로 분리시킵니다. 최상의 성능을 구현하려면 루트 관리 서버가 이 역할에 한정되어야 하며 어떠한 에이전트도 이 서버에 보고하도록 구성되어서는 안 됩니다.
새로운 게이트웨이 서버 역할은 관리 서버에 단일한 통신 경로를 제공함으로써 트러스트되지 않은 도메인과 경계 환경에서 관리 컴퓨터를 더욱 효율적으로 사용할 수 있게 해줍니다. 많은 경우 대상 도메인의 에이전트는 Kerberos 프로토콜을 통해 인증을 받고 게이트웨이 서버로 연결될 수 있으므로 인증서 기반 인증의 필요성을 최소화하고 관리 부담을 줄이며 TCO를 절감할 수 있습니다.

보고
사용자들은 아마 운영 콘솔에 보고 영역이 통합됨으로써 Operations Manager 2007의 보고 기능이 눈에 띄게 개선되었음을 알게 될 것입니다. 마찬가지로 보고 작업의 보안 역시 Operations Manager 전체 보안 기능에 통합되었습니다.
보고 데이터베이스에 데이터가 전달되는 방식과 시기 등을 포함하여 아키텍처가 여러 부분에서 크게 변화되었습니다. 야간을 이용하여 전날의 보고 데이터를 운영 데이터베이스에서 전송하는 DTS(데이터 전송 서비스)는 사라진 대신, 데이터가 운영 데이터베이스에 입력됨과 동시에 보고 데이터베이스에도 바로 입력되므로 시간 지연이 거의 없습니다.
Operations Manager 보고서에는 새로운 스마트 매개 변수 헤더가 들어 있어, 날짜와 시간을 특정한 관련 범위로 한정하여 보고할 수 있는 유연성을 제공합니다. 예를 들어 사용자가 지정한 업무 시간 범위 내로 보고 결과를 한정할 수 있습니다. 스마트 매개 변수 헤더의 개체 선택 검색 기능은 보고할 개체를 간단히 고를 수 있게 해줍니다. 보고서 일정을 지정하는 경우에도 보고서 정의 파일을 수정하지 않고도 날짜 선택기를 통해 반복되는 보고서에 특정한 관련 날짜 범위를 지정할 수 있는 유연한 기능을 제공합니다(그림 6 참조).
그림 6 업무 시간대 구성
그림 6 업무 시간대 구성
날짜 범위를 넓히더라도 보고서가 신속히 표시되도록 보고 기능이 향상되기도 했습니다. 이를 위해 Operations Manager에서 보고하는 데이터는 모든 Operations Manager 보고서에서 사용되는 시간별 및 일별 요약 데이터 요소로 미리 자동으로 인덱싱 및 집계됩니다. 따라서 데이터가 미리 수집될 뿐만 아니라, 기록 보고 기능에 영향을 주지 않고 원시 데이터 요소를 데이터베이스에서 훨씬 더 적극적으로 압축할 수 있으므로 데이터 웨어하우스의 확장성도 향상됩니다.
그러나 가장 인상적인 향상 내용은 네트워크 엔지니어와 IT 관리자에게 의미를 갖는 형태로 성능 기록 및 가용성 데이터를 표시하는 보고서 자체의 내용과 구성에 있습니다.
그림 7은 그래프와 표로 구성된 표준 성능 보고서입니다. 그림 8에 나와 있는 것과 같이 그래프의 선과 표의 설명을 클릭하면 상세한 보고서로 연결됩니다.
그림 7 표준 성능 보고서
그림 7 표준 성능 보고서
그림 8 성능 상세 보고서(드릴다운)
그림 8 성능 상세 보고서(드릴다운)
Operations Manager의 가용성 보고 작업은 개체의 상태를 기반으로 수행됩니다. 상태를 가질 수 있는 모든 개체는 가용성 보고서에서 바로 대상으로 사용할 수 있습니다. 또한 한 번만 클릭하면 상세 보고서에서 가용성 보고서로 이동할 수 있습니다(그림 9 참조).
그림 9 가용성 보고서
그림 9 가용성 보고서
보고서가 없는 관리 팩의 경우 거의 모든 관리 대상 개체의 가용성 및 성능 보고 기능을 제공하는 포괄적 보고서가 제공되므로 사용자 지정 보고서를 작성할 필요성이 크게 감소합니다.
다수의 관리 그룹이 하나의 보고 데이터 웨어하우스로 보고할 수 있는 기능을 Operations Manager 2007에서 지원하는 것은 관리자들이 환영할 만한 개선 사항이라 할 수 있습니다. 보고 보안 기능이 제품의 역할 기반 보안과 통합되었으므로 관리자들은 Active Directory 보안 그룹을 통해 보고서 액세스를 제어할 수 있습니다.

알림
알림 엔진은 Operations Manager 2007에서 완전히 바뀌어, 인스턴트 메시지 및 SMS(관리 서버에 타사 SMS 공급자를 설치해야 함) 등과 같은 새로운 알림 옵션(일명, 알림 채널) 등 관리자들이 간절히 요구하던 새로운 기능과 함께 등장했습니다. 이제는 알림 구독 기능에 범위 지정 옵션이 포함되어 작업자 역할 계정으로 볼 수 있는 개체 유형 및 그룹을 관리자가 제한해서 알림 구독의 대상을 더 정확히 지정할 수 있게 되었습니다.
경고 에이징(에스컬레이션) 기능을 이용하면 구독 설정에 지정된 기준에 부합하는 경고가 사용자가 지정한 기간 동안 일정한 해결 상태로 남아 있는 경우 알림 메시지가 전송되도록 할 수 있습니다.
메시지 형식을 구독 건별로 사용자 지정할 수 있게 되어 개별 사용자 수준에서 메시지 형식의 사용자 지정이 가능합니다. 또한 운영 콘솔의 내 작업 영역에 있는 셀프서비스 알림 기능을 이용하면 사용자가 자신의 알림 장치 및 구독 설정을 지정할 수 있습니다. 이러한 기능들은 이번 버전에서 제공되는 매우 편리한 알림 기능 가운데 일부일 뿐입니다.

관리 팩
관리 팩은 여전히 Operations Manager 2007의 서비스 및 응용 프로그램 모니터링 기능의 기본 틀로서 Microsoft 제품 팀으로부터의 응용 프로그램 관련 정보를 직접 제공해주고 있습니다. 그러나 제공되는 서비스의 상태에 초점을 맞추어, 서버 모니터링 방식에서 서비스 지향적 모니터링 방식으로의 변화가 이루어졌습니다.
지면의 제약으로 인해 여기서 자세히 다루지는 못하지만 MOM 2005의 단순한 개체 유형 모델(컴퓨터와 컴퓨터 그룹)이 모니터링 대상 개체 유형을 수십 가지 설정할 수 있는 신축성 있는 모델로 바뀌었다는 점은 반드시 짚고 넘어가야 합니다. 결과적으로 타사 ISV에서 특정 플랫폼에 구애받지 않는 우수한 기간 업무(LOB) 및 네트워크 솔루션을 공급할 수 있는 풍부한 개발 환경이 조성되었습니다.
MOM 2005에서 제공되던 것과 유사한 단순한 모니터링 규칙들이 텍스트 및 이벤트 로그 모니터링, WMI 이벤트 쿼리, 일정에 따른 스크립트 실행, 그리고 SNMP 관리 정보 수집의 필요성을 없애주는 대폭 개선된 SNMP 트랩 공급자 등과 같은 다양한 일상적 모니터링 작업에 사용됩니다.
그러나 Operations Manager의 모니터는 관리 대상 개체의 상태 변화를 감지합니다. 모니터에는 TCP 포트 검사, 데이터베이스 및 웹 사이트 접속을 위한 가상 트랜잭션, ASP.NET 응용 프로그램 및 웹 서비스 모니터링, 그리고 가장 중요한 것으로, 분산된 LOB 응용 프로그램에 대한 서비스 지향적 모니터링 등 MOM 2005 공급자에는 없었던 여러 가지 기능이 추가되었습니다. 그러면 잠시 이에 관한 사항을 좀 더 자세히 살펴보겠습니다.

자동 튜닝 임계값
때때로 특정 카운터의 동작을 알 수 없는 경우가 있습니다. 그와 같은 상황에서 Operations Manager는 자동 튜닝 임계값 모니터를 제공합니다. 자동 튜닝 임계값 모니터는 지정된 업무 주기(통상적으로 일주일, 짧은 경우 하루)에 걸친 학습 과정을 통해 지정된 성능 카운터 개체의 통상적인 값을 파악하고, 학습 기간 중 기록된 운영 기준에 근거하여 임계값을 정합니다. 이 임계값은 리소스 사용량의 급격한 상승 또는 하락을 비롯하여 야간 응용 프로그램 및 시스템 유지 관리를 실시하는 도중에 나타날 수 있는 예상 동작을 나타냅니다.

가상 트랜잭션
Operations Manager는 응용 프로그램의 상태를 보다 동적으로 파악할 수 있도록, 모니터링되는 개체에 대해 실시간으로 실행되는 동작인 가상 트랜잭션을 제공합니다. 가상 트랜잭션은 웹 사이트 탐색 시퀀스, 데이터베이스 연결, TCP 포트 모니터링 등을 위해 생성될 수 있습니다. 트랜잭션이 실행될 서버 노드(감시자 노드)뿐만 아니라 원하는 모니터링 간격도 지정할 수 있습니다. 감시자 노드가 여러 개 선택된 경우에는 그 결과를 비교하여 각 노드의 경험이 동일한지 파악할 수 있습니다.
웹 브라우저 시퀀스 캡처에 사용되는 웹 응용 프로그램 편집기는 또한 관리자가 경고 및 오류 수준 응답 시간 임계값을 정의하고 페이지 로드 및 링크 검색 프로세스의 개별 작업에 대한 일련의 성능 카운터를 지정할 수 있게 해줍니다. 기본 인증, NTLM 인증 등 다양한 인증 방법이 요구되는 보안(SSL) 브라우저 시퀀스가 지원됩니다.
MOM 2005에서 친숙한 개념인 다시 정의 작업은 개체 또는 관리 대상 개체 그룹의 모니터, 특성 및 규칙에 대한 Operations Manager 설정 구성을 조정하는 데 사용됩니다(그림 10 참고). 다시 정의 기능의 사용은 Operations Manager에서 수집되는 데이터의 양을 조절하는 데 핵심적인 역할을 합니다. 그룹과 다시 정의 기능을 함께 사용하면 모니터, 규칙, 특성 또는 개체 검색의 초점을 자신의 관리 팩뿐만 아니라 Microsoft 및 타사 ISV 관리 팩의 대상 개체 그룹으로도 좁힐 수 있습니다.
그림 10 서비스 모니터의 다시 정의 매개 변수
그림 10 서비스 모니터의 다시 정의 매개 변수

LOB 응용 프로그램 모니터링
새로운 Distributed Application Designer를 이용하면 중요 응용 프로그램의 서비스 수준 상황도를 작성하고, 분산 응용 프로그램 구성 요소에 대해 요약된 상태 지표를 제공할 수 있습니다. 여기에는 웹 서비스, SQL Server™ 데이터베이스, 그리고 네트워크 라우터 및 스위치 등 Windows와 관계 없는 장치를 비롯하여 모든 발견된 개체 유형이 포함됩니다. 따라서 개체 관계 및 현재 상태 등을 다이어그램으로 볼 수 있습니다.
이러한 강력한 기능에 대한 접근성을 높이기 위해 Microsoft는 몇 가지 분산 응용 프로그램 템플릿을 제공하여 관리자들이 고유 LOB 응용 프로그램을 정의할 수 있는 출발점으로 삼도록 하고 있습니다. ASP.NET 응용 프로그램 및 ASP.NET 웹 서비스, LOB 웹 응용 프로그램, 메시징, SharePoint® 포털 팜, 터미널 서비스 팜 등 수많은 일상적인 시나리오를 위한 템플릿이 제공됩니다.
Microsoft 또는 타사 관리 팩을 통해 관리 그룹에 새로운 템플릿을 추가할 수 있으며, 이는 추가 모니터링 마법사(Add Monitoring Wizard)에 표시됩니다. Active Directory, Exchange, Operations Manager 등에 대한 분산 응용 프로그램 모니터는 사전 배포되며 수정이 불가능합니다.

관리 팩 가용성
Operations Manager 2007 전용으로 제작된 관리 팩(최적 관리 팩)은 Operations Manager 2007의 새로운 기능을 활용할 수 있도록 설계되었으며 2008년부터 새로운 소프트웨어 버전으로 제공될 예정입니다. 그러나 기존 MOM 2005 관리 팩도 MPConvert 유틸리티를 이용하여 Operations Manager 2007 지원 형식으로 변환할 수 있으며, MOM 2005-Operations Manager 2007 마이그레이션 도구를 이용하여 기존에 설치된 MOM 2005로부터 전환될 수 있습니다. 두 도구 모두 Operations Manager 2007 CD에 있습니다. Microsoft는 MOM 2005 관리 팩을 Operations Manager 2007 호환 형식으로 변환하는 중이므로 일반적으로 이 도구는 자체 제작 관리 팩을 사용하는 경우에만 필요할 것입니다.

감사 수집
감사 수집 기능을 이용하면 수집 작업을 자동으로 처리하고 분산된 Windows 보안 이벤트 로그를 한 곳에 집중해서 보관할 수 있습니다. 이 기능은 내부 및 외부 규정 준수 감사를 위해 대량의 보안 이벤트 로그 데이터를 수집하고 분석해야 하는 중대 규모 기업용으로 설계되었습니다. 감사 수집은 수집기, 전달자, 데이터베이스, 보고 등 네 가지 역할로 구성됩니다. 수집기는 이벤트를 '포착'하여 이를 감사 수집 데이터베이스에 넣는 서버를 말합니다. 전달자는 보안 이벤트 로그 이벤트를 거의 실시간으로 전송하여 로컬 관리자가 보안 로그 이벤트에 지장을 줄 가능성을 최소화하는 서비스입니다. 전달자 서비스는 Operations Manager 2007 에이전트에 포함되어 있지만 해당 에이전트에 대해 감사 수집이 사용되기 전까지는 사용이 중지되어 있습니다.
감사 수집은 자동 야간 데이터베이스 유지 관리 기능을 채택하고 있어, 대규모 데이터 집합 전반에서 일관되게 양호한 보고서 표시 성능을 보장합니다. 감사 수집은 관리자가 소속 조직의 요구 사항에 맞게 조정할 수 있는 순환식 데이터 집합을 유지 관리(기본적으로 14일간 저장)합니다. 수집된 이벤트의 분석을 위해 감사 수집에는 고성능 WMI 구독자뿐만 아니라 약 20개의 기본 감사 보고서 집합 등의 보고 역할이 들어 있어, 관리자에게 데이터베이스 액세스 권한을 직접 부여할 필요 없이 임시 쿼리를 수행할 수 있는 쉽고 편리한 인터페이스를 제공합니다.

클라이언트 모니터링
Operations Manager 2007의 새로운 클라이언트 모니터링 기능은 관리자가 데스크톱 운영 체제와 응용 프로그램을 모니터링하고 자주 발생하는 오류를 파악하여 조직에 가장 이익이 되는 방향으로 역량을 집중할 수 있도록 해줍니다. 수집된 오류 데이터는 자세한 보기 및 보고서 생성에 사용되어 의사 결정 지원에 즉각 활용할 수 있는 정보원을 제공합니다.
Operations Manager 2007의 실제 클라이언트 모니터링 기능은 세 가지 수준으로 이루어져 있으며 각 수준은 개별적으로 설정할 수 있습니다.
AEM(에이전트 없이 예외 감시) 이 기능은 운영 체제와 응용 프로그램의 충돌과 오류를 모니터링할 수 있게 해줍니다. 과거에는 관리자가 이 보고서를 Microsoft에 직접 보냈지만 이제는 관리 서버에 먼저 보낸 후 선택적으로 Microsoft에 전달할 수 있습니다.
CEIP(사용자 환경 개선 프로그램) CEIP에 참가하면 그룹 정책을 통해, 보고서를 Microsoft로 직접 보내지 않고 Operations Manager 2007 관리 서버로 보내도록 클라이언트를 구성할 수 있습니다. 그리고 관리 서버는 이 보고서를 Microsoft로 보내도록 구성됩니다.
AEM 및 CEIP 클라이언트 모니터링 구성 요소는 에이전트 없이 수행될 수 있다는 점에 유의하십시오.
중요 업무용 워크스테이션에 대한 클라이언트 모니터링 Operations Manager 에이전트를 중요 업무용 데스크톱에 실제로 배포하는 것과 관련한 작업입니다. 관리 팩에는 Windows 2000, Windows XP, Windows Vista용 에이전트, 그리고 Microsoft Office, Internet Explorer 및 기타 Microsoft 데스크톱 응용 프로그램을 모니터링하는 Microsoft Information Worker가 포함됩니다.

평가판 안내
지금까지 살펴본 바와 같이 System Center Operations Manager 2007은 서비스 지향 모니터링 기능을 제공하고 적절한 곳에 통합할 수 있도록 설계된 수많은 기능을 도입하여, Active Directory에 대한 기존의 시간/비용 투자를 활용하고 관리 작업을 능률화하고 TCO를 절감할 수 있게 해줍니다. 훌륭한 기능을 갖춘 이 새로운 버전을 사용하면서 그 가능성을 확인해보시기 바랍니다.
microsoft.com/technet/opsmgr/2007/downloads/trials/privacy.mspx에서 Operations Manager 2007의 180일 평가판을 다운로드할 수 있습니다. Microsoft System Center 기술에 대한 자세한 내용은 System Center Operations Manager 홈 페이지(microsoft.com/systemcenter/opsmgr)를 참조하십시오. 새로운 "Designed for BIG" 웹 사이트와 관련한 System Center 센터의 성공 사례(비디오 및 사례 연구)는 designedforbig.com을 참조하십시오.

Pete Zerger는 AKOS Technology Services의 컨설팅 파트너입니다. Pete는 IT 업계에서 9년간 일해왔으며, 현재는 엔터프라이즈 운영 관리, 디렉터리 서비스, 메시지 솔루션 등의 설계와 구축에 주력하고 있습니다. 또한 MCSE for Messaging, MCTS for SQL Server 2005 자격증을 보유하고 있으며 Microsoft MVP for Microsoft Operations Manager 자격도 가지고 있습니다.


 System Center: MOM을 Operations Manager 2007로 마이그레이션
System Center Andy Dominey

MOM을 Operations Manager 2007로 마이그레이션
한 눈에 보기:
  • Operations Manager 배포 계획
  • 하드웨어 요구 사항 평가
  • 과거 데이터 보존
  • 테스트 계획

서버 모니터링과 관리는 현대의 모든 IT 인프라에서 매우 중요한 부분입니다. IT 인프라가 제대로 운영되고 사용자들의 로드를 적절히 지원하도록 하는 것이 절대적으로 중요하기 때문입니다. 그러나 이와 관련한 정보를 수집하는 일이
말처럼 쉬운 것은 아니며 수집된 정보를 처리하는 것은 또 전혀 다른 문제입니다. 다행히 도움이 될 만한 솔루션이 있습니다. Microsoft® Operations Manager(MOM)는 지난 7년간 이와 같은 과제의 처리를 지원해 왔으며 그 최신 버전인 System Center Operations Manager 2007은 한층 더 향상된 능력을 선보이고 있습니다.

왜 마이그레이션해야 하는가?
System Center Operations Manager 2007은 기존 버전인 MOM 2005에 비해 많은 부분이 크게 개선되었습니다. 핵심 아키텍처가 재설계되었으며, 여러 장치에서 사용되는 응용 프로그램에 대한 인식 기능이 향상되었으며 서버뿐만 아니라 하나의 서버를 구성하는 모든 구성 요소를 인식할 수 있도록 획기적으로 개선되었습니다.
또한 Operations Manager는 경고 데이터를 집계하면서 잘못된 경고의 수를 크게 줄일 수 있는 강력한 데이터 정렬 엔진과 문제 소재 확인 및 해결 과정을 원활하게 하는 Health Explorer를 지원합니다.
사용자 환경 전체의 시스템 성능 활용도를 쉽게 추적할 수 있게 해 주는 자동 튜닝 임계값과 기준 설정 엔진(baselining engine)을 갖추고 있으며 보고 엔진이 크게 개선되어 탁월한 그래픽과 드릴스루 보고 기능을 제공합니다. 그림 1을 통해 보고 데이터가 시각적으로 어떻게 표현되는지 살펴보시기 바랍니다.
그림 1 Operations Manager 2007의 가용성 보고서
그림 1 Operations Manager 2007의 가용성 보고서
Operations Manager는 서버뿐만 아니라 데스크톱 컴퓨터도 모니터링할 수 있습니다. 다음은 Operations Manager 2007에 새로 추가된 기능의 일부입니다.
  • Windows Server System™ 플랫폼에 대한 탁월한 모니터링 기능
  • 강력한 응용 프로그램 모니터링 기능
  • 일상적인 작업의 자동화
  • 엔터프라이즈 수준의 확장과 제어를 용이하게 해 주는 차세대 데이터베이스 엔진
  • 보안 강화 및 Active Directory® 통합
System Center Operations Manager 2007의 새로운 기능에 대한 자세한 내용은 TechNet Magazine 이번 호에 실린 Pete Zerger의 "탁월한 서버 모니터링 기능을 제공하는 Operations Manager 2007"을 참조하십시오.

Operations Manager로의 마이그레이션
Operations Manager 2007로의 마이그레이션 계획을 수립하기 전에, 직접 업그레이드는 불가능하다는 점을 인지해야 합니다. Operations Manager의 아키텍처 자체에 너무나 중요한 변화가 있었기 때문에 사용 중 업그레이드를 수용할 만큼 기존 버전과의 호환성을 유지할 수 없었습니다. 따라서 현재 MOM 2000 또는 MOM 2005를 실행 중이라면 이 기사에서 설명하는 마이그레이션 전략 중 하나를 선택해야 할 것입니다.
기존 버전의 MOM을 실행하고 있지 않다면 그냥 새로운 버전만 설치하면 됩니다. 그러나 설치 또는 마이그레이션 수행이 가능한 숙련된 기술을 충분히 보유하고 있는지 아니면 외부의 지원이 필요한지 여부를 최대한 조기에 판단해야 할 것입니다. 이 사항은 프로젝트의 전체적인 비용에 영향을 미칠 것이 분명하므로 착수 단계에서 충분히 고려되어야 합니다.

마이그레이션 시나리오
현재 MOM이 실행되지 않는 환경이라면 구축 작업은 간단합니다. 계획 및 아키텍처 설계 단계를 거쳐 소프트웨어를 설치하기만 하면 됩니다. 그러나 현재 MOM을 사용하고 있을 경우, Microsoft는 두 가지 마이그레이션 시나리오, 즉 같은 하드웨어에 병행 설치하는 방식과 다른 하드웨어에 병행 설치하는 방식을 지원합니다. 그러면 두 방식을 모두 살펴보겠습니다.
같은 하드웨어에 병행 설치 이 시나리오에서는 Operations Manager를 기존 MOM 2000 또는 MOM 2005 아키텍처와 동일한 하드웨어에 설치합니다. 이 방식은 MOM 인프라의 사용률이 크게 높지 않고 서버 하드웨어가 기존 버전과 새로운 버전을 함께 호스팅하기에 충분한 처리 능력을 갖고 있는 경우에 유용합니다. 따라서 이 방식은 Operations Manager의 설치가 기존 MOM 서버의 성능에 심각한 부담을 주지 않을 경우에만 선택해야 합니다.
다른 하드웨어에 병행 설치 이 방식에서는 Operations Manager를 새로운 하드웨어 또는 다른 하드웨어에 새로 설치합니다. 마이그레이션이 진행되는 동안 기존 관리 인프라에 거의 부담을 주지 않기 때문에 이 방식이 보다 선호됩니다. 그런데 반드시 하드웨어를 추가할 필요는 없다는 점을 기억하십시오. 새로운 Operations Manager 2007 서버는 기존 서버 하드웨어가 재할당될 때까지 가상 시스템에 스테이징(stage)될 수 있습니다.

고려 사항
특정한 마이그레이션 전략을 실행하기 전에 고려해야 할 몇 가지 중요한 사항이 있습니다.
첫째, 하드웨어 및 소프트웨어 요구 사항과 관련 비용을 고려해야 합니다. Operations Manager 인프라의 일부 또는 전체를 가상 시스템에 스테이징 또는 구축하는 경우에도 Operations Manager에서 모니터링하는 각 에이전트의 OML(운영 관리 라이선스)과 OS 및 응용 프로그램의 라이선스가 필요합니다.
둘째, 작업을 수행할 인력 및 리소스 확보 계획을 수립해야 합니다. 소규모 기업이라면 계획 수립이 특별히 복잡하거나 어렵지 않겠지만 규모가 큰 기업이라면 전체적인 마이그레이션 전략에서 매우 중요한 부분이 될 것입니다.
또한 이 마이그레이션 작업이 기존 모니터링 인프라 또는 서버 자산에 전체적으로 미칠 수 있는 잠재적 영향도 고려해야 합니다. 서버 다시 부팅은 물론 중요한 프로덕션 서버의 장애 가능성까지 모든 우발적 사태에 대비할 수 있는 계획을 마련해야 합니다.
보관 데이터의 저장 및 보고를 위해 MOM 2000 환경에서 Microsoft Access™ 데이터베이스를 사용하고 있거나 MOM 2005 환경에서 SQL Server™ 데이터 웨어하우스를 사용하고 있는 경우 해당 데이터를 Operations Manager 2007로 마이그레이션하는 기능은 현재 지원되지 않는다는 점에 유의하십시오.

성공적인 마이그레이션을 위한 계획 수립
컨설턴트인 필자의 시각에서 볼 때 부적절한 배포 계획은 가장 큰 문제 중 하나입니다. 새 하드웨어에 설치할 것인지 기존 하드웨어에 설치할 것인지 결정했으면 다음 단계에서는 프로젝트 계획을 수립해야 합니다.
비록 충분하지는 않지만 이 기사에서 제시한 프로젝트 단계는 프로젝트 계획에 반드시 포함되어야 합니다. 프로젝트의 각 단계에 충분한 시간을 배정하고, 필요한 모든 리소스를 고려하십시오.
앞서 언급했듯이 System Center Operations Manager 2007의 아키텍처는 MOM 2000 및 2005와 크게 다릅니다. 무엇보다, Operations Manager에는 RMS(루트 관리 서버)라는 새로운 서버 역할이 추가되었습니다. RMS는 관리 그룹을 위한 구성을 관리하고 다른 관리 그룹 및 타사 제품에 대한 모든 연결을 처리하며, 관리 그룹의 보안도 담당합니다. 이 역할은 기존 System Center Operations Manager 관리 서버에서 담당할 수 있지만 시스템 환경의 규모가 크고 복잡할 경우에는 전용 서버를 배정해야 합니다. 또한 MOM 2005에 존재했던 계층형 관리 그룹이라는 개념은 연결된 관리 그룹(Connected Management Group)으로 대체되었습니다. 이 새로운 아키텍처에서는 실제 경고 데이터가 관리 그룹 간에 전달되지 않으며, 연결된 관리 그룹에서 내보낸 경고가 요청 중인 관리 그룹의 UI에 표시됩니다. 또한 트러스트되지 않은 도메인 또는 작업 그룹의 컴퓨터에 에이전트를 설치하고자 한다면 반드시 인증서를 사용해야 에이전트와 관리 서버의 상호 인증(Operations Manager에서 강제하는 기능)이 가능합니다.
System Center Operations Manager를 위한 아키텍처를 설계하려면 모니터링하려는 서버와 클라이언트의 수, 그 위치가 트러스트된 도메인인지 여부, 모니터링해야 하는 응용 프로그램과 플랫폼, 네트워크 인프라를 모니터링하려고 하는지 여부 등을 고려해야 합니다. 또한 사용자 지정 규칙 또는 관리 팩을 요구하는 응용 프로그램도 파악해야 합니다.
이 단계에서 관리 팩의 요구 사항을 파악해야 합니다. 모니터링할 응용 프로그램이 결정되었으면 설치할 관리 팩을 결정할 수 있습니다. 관리 팩에는 특정 응용 프로그램 또는 운영 체제에 적용되는 규칙, 모니터, 작업, 클래스 등이 포함되며, 시스템 환경에서 관련 응용 프로그램 또는 운영 체제를 사용하고 있다면 반드시 가져와야 합니다. 이 단계에서 이루어지는 관리 팩에 대한 선택은 하드웨어 및 소프트웨어 요구 사항, 그리고 소프트웨어 설치 및 구성에 할애해야 하는 시간에 영향을 미칩니다.
Operations Manager 인프라의 아키텍처에 대한 구상이 세워졌으면 System Center Capacity Planner 2007이라는 도구(본 기사 작성 시점에는 베타 버전임)를 꺼낼 차례입니다. 이 도구를 이용하여 네트워크 및 서버 인프라의 구체적인 계획을 마련하고 Operations Manager 배포 계획을 대상으로 시뮬레이션을 실행하여 인프라를 충분히 모니터링, 관리할 수 있는지 점검합니다.
마이그레이션을 계획하고 있다면, 이 시점에서 아키텍처 설계에도 특별한 관심을 기울여야 합니다. MOM 200x가 Operations Manager와 함께 실행되면 네트워크 트래픽이 늘어난다는 사실도 고려해야 합니다.

배포
다음 단계로 배포를 고려해야 합니다. 소프트웨어를 설치하려면 먼저 적절한 하드웨어가 준비되었는지 확인할 필요가 있습니다. 새로운 환경에 소프트웨어를 설치한다면, 특히 데이터베이스 서버의 경우라면 하드웨어를 새로 마련하는 것이 좋습니다. 그러나 하드웨어를 마련할 수 없다면 관리 서버를 가상화할 수 있습니다. 마이그레이션하는 경우, 하드웨어를 새로 구입하지 않고 가상화된 서버를 사용해도 새로운 인프라를 충분히 스테이징(stage)할 수 있습니다. 이러한 상황이라면 기존 MOM 서버가 사용 중지되고 재구성되는 동안 가상 시스템을 사용하여 Operations Manager를 스테이징할 수 있습니다.
서버가 준비되면 소프트웨어 설치를 시작할 수 있습니다. 우선, Operations Manager를 실행할 서버에 필요한 소프트웨어가 갖춰져 있는지 확인합니다. 예를 들어 SQL Server 2000을 실행하는 서버에 Operations Manager를 설치할 계획이라면 먼저 SQL Server 2005 SP1로 업그레이드해야 합니다. 이를 확인하려면 System Center Operations Manager 설치 미디어에 있는 Operations Manager 필수 구성 요소 확인 도구(prerequisite checker)를 실행합니다.
소프트웨어 준비 조건을 모두 갖추고 SQL Server와 Reporting Services를 구성했으면 Operations Manager 소프트웨어 설치를 시작할 수 있습니다. 단일 서버 환경의 경우에는 설치 작업이 간단합니다. 서버에서 Operations Manager 설치 파일을 실행하고, 필요한 경우 Operations Manager 보고 기능을 설치하면 됩니다. 그러나 분산 환경의 경우에는 Operations Manager 구성 요소를 개별 서버에 정확한 순서로 설치해야 합니다. 먼저 데이터베이스를 설치하고 첫 번째 관리 서버를 설치하면 루트 관리 서버 역할이 자동으로 할당됩니다. 그 후에 다른 관리 서버를 설치할 수 있습니다. 마지막 단계에서 웹 콘솔과 보고 구성 요소를 설치합니다.

마이그레이션
이 단계에서는 새로운 기능을 실행하기 전에 새 인프라가 기존의 모니터링 기능을 정확히 반영하고 있는지 확인해야 합니다. 기존 환경에서 사용되던 모든 관리 팩이 새로운 Operations Manager 배포에 정확히 복제되어야 합니다. 기존의 Operations Manager 관리 팩을 그대로 가져올 수 있다면 좋겠지만 새로운 버전이 아닌 관리 팩은 기존 관리 그룹에서 내보낸 다음 설치 CD에 있는 MPConvert 도구를 통해 변환해서 Operations Manager로 가져와야 합니다. 크기가 작거나 간단한 사용자 지정 관리 팩이라면 새로 만드는 편이 낫습니다. 이 도구는 구성을 복제할 때도 유용합니다. MOM 2005 - Operations Manager 마이그레이션 도구는 기존 MOM 관리 그룹에서 Operations Manager로 구성을 복제할 때 도움이 됩니다. 이 도구도 Operations Manager 설치 CD에 있습니다. 그림 2는 마이그레이션이 진행되는 동안의 일반적인 구성을 보여 줍니다.
그림 2 마이그레이션 중의 일반적인 구성
그림 2 마이그레이션 중의 일반적인 구성
구성이 복제되었으면 Operations Manager가 MOM과 동일한 경고를 실제로 내보내고 동일한 데이터를 수집하는지 확인해야 합니다. 다행히 Operations Manager 에이전트는 기존 MOM 에이전트와 공존할 수 있으므로 두 에이전트를 동시에 실행할 수 있습니다. 따라서 구형 시스템의 가동을 중단시키기 전에 두 에이전트로부터 데이터를 수집하여 비교할 수 있습니다.
다음으로 체계적인 테스트 계획을 세워야 합니다. 테스트는 단순히 기존 시스템의 경고를 Operations Manager 시스템의 경고와 비교하는 것으로 끝날 수도 있지만, 새로운 시스템을 철저히 평가하기 위해서는 의도적으로 경고를 발생시켜야 할 수도 있습니다. 테스트 결과에 만족한다면 MOM 콘솔 또는 에이전트 컴퓨터의 프로그램 추가/제거 기능을 이용하여 기존 MOM 에이전트 제거 작업을 시작할 수 있습니다.
보고는 MOM과 System Center Operations Manager 배포에서 큰 부분을 차지하는 기능이므로, 역시 설명이 필요합니다. 기존 SystemCenterReporting 데이터베이스는 현재 Operations Manager 2007로 마이그레이션할 수 없는 상태이므로 Operations Manager를 위한 Reporting Services 인스턴스를 새로 만들고, MOM 2005(SystemCenterReporting) 데이터베이스는 기존 보고서를 표시할 수 있도록 기존의 전용 SQL Reporting Services 인스턴스에 유지해야 합니다. System Center Operations Manager 2007의 새로운 보고 콘솔인 Reporting Services 콘솔은 제품 자체에 통합되었으므로 Operations Manager가 아닌 다른 용도로 사용하는 것은 바람직하지 않습니다. 보고 데이터의 마이그레이션 문제는 향후 데이터 마이그레이션 스크립트를 통해 해결될 수도 있겠지만 그때까지는 보관된 보고 데이터에 작별을 고하시되, 새롭고 화려한 보고서를 만들어내기 시작하면 경영진은 너무 좋아서 기존 데이터가 없어졌다는 것을 알아채지 못할 것이라는 사실로 위안을 삼으시기 바랍니다.

결론
System Center Operations Manager는 MOM 2000과 2005에 비해 크게 개선되었지만 그 혜택을 누리기 위해서는 어느 정도 대가를 치러야 합니다. 근간이 되는 아키텍처가 대대적으로 변경되었다는 점, 그에 따라 사용 중 업그레이드가 지원되지 않는다는 사실은 배포 비용이 늘어날 수 있음을 의미합니다. 이러한 비용을 최소화하는 열쇠는 올바른 계획을 수립하고 적절한 인력을 확보하는 데 있습니다. 그러한 준비에 성공한다면 Microsoft가 System Center Operations Manager에 기울인 노력의 결과물을 여러분의 것으로 만들 수 있을 것입니다.

Andy Dominey는 IT 업계에서 8년간 종사했으며 현재는 영국의 1E에서 Windows 관리 전문가로 근무하고 있습니다. 그는 MOM 2000부터 MOM을 다뤄 왔으며 Microsoft에서 과거 2년간 MOM 분야의 MVP로 선정되었습니다.


 System Center: Microsoft SoftGrid를 이용한 응용 프로그램 가상화
System Center Ahmer Sabri and Kedar Shah

Microsoft SoftGrid를 이용한 응용 프로그램 가상화
한 눈에 보기:
  • 응용 프로그램 가상화의 이점
  • SoftGrid 아키텍처 개요
  • 소프트웨어 패키지 스트리밍

소프트웨어 가상화라는 개념은 1960년대부터 다양한 형태로 제시되었지만 IT 산업에서 그 잠재력을 깨닫게 되기까지는 수십 년의 시간이 흘러야 했습니다.
이제 업계에서는 소프트웨어 가상화에 대해 이해하고 중요한 발전을 이루고 있습니다.
Microsoft는 응용 프로그램 가상화에 어느 정도 역점을 두고 2006년 7월 Softricity를 인수했으며, 그 결과 Microsoft® SoftGrid라는 응용 프로그램 가상화 솔루션이 개발되었습니다. SoftGrid를 사용하면 응용 프로그램이 데이터 센터 또는 다른 네트워크 위치에서 제공되어 가상 환경의 원격 클라이언트에서 로컬로 실행됩니다. 이 가상 응용 프로그램은 격리된 상태로 실행되며 로컬 데스크톱의 운영 체제 및 다른 응용 프로그램과는 독립적으로 작동합니다.
SoftGrid를 통해 응용 프로그램 가상화를 구현할 때 얻을 수 있는 이점은 매우 많아 이 칼럼에서 모두 다룰 수는 없지만, 가장 중요하고 바로 체감할 수 있는 이점으로는 다음과 같은 것이 있습니다.
회귀 테스트 및 호환성 테스트 간소화 동일한 응용 프로그램의 여러 버전을 단일 컴퓨터에서 충돌 없이 병렬로 실행함으로써 새 응용 프로그램을 테스트 및 배포하는 것과 관련된 복잡성, 시간 및 비용을 상당히 절감할 수 있습니다(그림 1 참고).
그림 1 SoftGrid를 통한 응용 프로그램 배포 효율성 향상
그림 1 SoftGrid를 통한 응용 프로그램 배포 효율성 향상
더욱 간편한 시스템 관리 IT 부서에서 이러한 응용 프로그램이 실행되는 환경을 더욱 강력하게 제어할 수 있으므로 이상적인 데스크톱 환경을 더욱 편리하게 유지 관리할 수 있습니다.
지원 부서의 업무 부담 완화 가상 응용 프로그램이 제어되는 격리된 상태로 실행되므로 데스크톱 환경이 더욱 효율적으로 관리되고 충돌이 감소하므로 지원 부서의 업무 부담이 완화됩니다.
데스크톱 보안 향상 응용 프로그램이 OS에 설치되지 않으므로 OS 보안이 전반적으로 향상됩니다. 권한이 있는 사용자만 응용 프로그램에 액세스할 수 있으므로 무단 액세스를 방지할 수 있습니다. 또한 대부분의 응용 프로그램이 표준 보안 컨텍스트에 따라 표시됩니다.
자유로운 사용자 환경 구현 프로필 및 기타 설정 등 사용자의 기본 설정이 네트워크에 저장되므로 사용자가 어느 PC에서든 자신의 응용 프로그램, 기본 설정 및 컨트롤에 액세스할 수 있습니다.
내결함성 및 재해 복구 성능 향상 응용 프로그램은 다른 엔터프라이즈 데이터처럼 저장 및 복제가 가능한 데이터 파일로 변환됩니다. 응용 프로그램과 해당 업데이트는 타사 도구를 사용하여 라이브 사이트와 BCP(대량 복사 프로그램) 사이트 간에 자동으로 동기화되므로 재해가 발생하더라도 응용 프로그램에 바로 액세스할 수 있습니다.
결과적으로 이러한 이점 덕분에 시스템 관리 부담과 비용을 낮추고 새로운 기술을 더욱 신속하고 안정적으로 도입할 수 있습니다. 그러면 SoftGrid의 작동 방식에 대해 자세히 살펴보겠습니다.

가상 응용 프로그램 제공 방식
SoftGrid 아키텍처는 조화롭게 작동하는 여러 구성 요소로 이루어져 있습니다. 즉, 데이터 저장소, 가상 응용 프로그램 서버, 시퀀서, 관리 콘솔, 관리 웹 서비스, 클라이언트 응용 프로그램 등의 SoftGrid 구성 요소가 Active Directory®와 같은 표준 인프라 구성 요소와 함께 작동합니다(그림 2 참조). 이제 SoftGrid 아키텍처를 개괄적으로 살펴보고 다양한 구성 요소가 어떻게 상호 작용하는지 설명하겠습니다.
그림 2 SoftGrid 아키텍처 개요
그림 2 SoftGrid 아키텍처 개요
SoftGrid 데이터 저장소는 전체 가상화 환경에서 하나의 중앙 리포지토리 역할을 수행합니다. 데이터 저장소는 SQL Server™(2000 또는 2005 버전) 또는 Microsoft SQL Server Desktop Engine(MSDE)에 설치되어 레코드, 응용 프로그램, 구성, 라이선스 데이터, 보고서 정보, 로깅 정보 등을 저장합니다.
가상 응용 프로그램은 사용자의 컴퓨터에 제공되어 클라이언트에 표시됩니다. SoftGrid에는 Microsoft SoftGrid Application Virtualization for Desktops와 Microsoft SoftGrid Application Virtualization for Terminal Services의 두 가지 유형이 있습니다. 각 유형마다 고유한 이점과 성능상의 특징이 있습니다. 이에 대한 자세한 내용은 '클라이언트 설정' 섹션에서 다루겠습니다.
SoftGrid 환경에서 가장 중요한 구성 요소 중 하나는 SVAS(SoftGrid 가상 응용 프로그램 서버)입니다. 이 구성 요소는 응용 프로그램에 대한 사용자의 요청을 처리하고 사용자가 요청한 응용 프로그램 데이터를 스트리밍하는 데 사용됩니다.
SVAS는 Microsoft System Center Virtual Application Server라고 하는 Windows® 서비스로서 실행되며 하드웨어 요구 사항도 까다롭지 않습니다. 잠시 후 설명할 응용 프로그램 데이터 자체는 기본적으로 모두 \Program Files\Softricity\SoftGrid Server\content 디렉터리에 저장됩니다.
사용자가 워크스테이션에 로그온할 때 일반적인 SoftGrid 환경이 시작됩니다. SoftGrid 클라이언트는 사용자의 보안 토큰과 도메인 그룹 구성원 자격을 캡처하고 보안 채널을 통해 이 정보를 SVAS로 전송합니다. 사용자의 SID(보안 식별자)가 응용 프로그램의 그룹 구성원 디렉터리에 존재할 경우 SVAS는 해당 사용자에게 응용 프로그램에 대한 액세스 권한을 부여합니다. 그러면 각 응용 프로그램에 대한 바로 가기가 사용자의 바탕 화면이나 시작 메뉴, 빠른 실행 도구 모음 등 관리자가 지정한 곳에 생성됩니다.
일반적으로 응용 프로그램 실제 전달은 사용자가 Open Software Description 파일(.osd)과 연결된 바로 가기 아이콘을 클릭할 때 시작됩니다. .osd 파일은 응용 프로그램 패키지에 관한 정보가 포함된 XML 기반 파일입니다. 클라이언트는 .osd 파일에서 가상 응용 프로그램 서버 이름을 검색하여 연결을 시작합니다. 이때 SVAS는 클라이언트를 인증하고 데이터 저장소에 연결하여 라이선스가 올바른지 확인합니다. 사용자에 대한 인증이 이루어지면 SVAS는 응용 프로그램 데이터를 데이터 블록 단위로 나누어 클라이언트에게 스트리밍합니다. 기본적으로 데이터 블록은 32KB 단위이지만 시퀀스를 지정할 때 다르게 구성할 수 있습니다.
이 경우 응용 프로그램 전체가 클라이언트에게 스트리밍되는 것은 아니라는 점에 주의해야 합니다. SoftGrid는 클라이언트에서 응용 프로그램을 실행하는 데 반드시 필요한 부분만 스트리밍합니다. 물론 응용 프로그램에 따라 차이가 있을 수 있지만 일반적으로 전체 코드의 약 20~40% 정도가 스트리밍됩니다. 예를 들어 Microsoft Word 2003의 경우 패키지의 전체 크기는 800MB에 이르는 반면에 클라이언트에서 실행할 수 있도록 스트리밍되는 데이터 크기는 15MB에 불과합니다. 사용자가 클라이언트의 캐시에 없는 응용 프로그램 부분에 액세스하면 필요한 코드가 클라이언트에게 스트리밍됩니다. 조직에서는 월요일 아침 현상, 즉 요청이 동시에 너무 많이 몰려서 네트워크 정체가 발생하는 상황을 피하기 위해 자주 사용되는 응용 프로그램을 사용자의 데스크톱에 미리 캐시하는 방법을 고려해 볼 수도 있습니다.

Active Directory
SoftGrid는 Active Directory 또는 Windows NT® 4.0 도메인 사용자 및 그룹을 사용하여 권한이 있는 사용자에게 응용 프로그램을 제공합니다. 다중 도메인 환경에서는 SVAS가 설치된 도메인과의 트러스트 관계 및 적절한 그룹 구성원 자격(SoftGrid는 로컬, 글로벌 및 유니버설 그룹 구성원 자격을 지원함)을 사용하여 사용자에게 응용 프로그램을 제공할 수 있습니다.
SVAS를 설치할 때는 여러 서비스 계정과 그룹을 설정할 것인지 묻는 메시지가 표시되는데, 이 계정과 그룹은 Active Directory와 통합하는 데 유용하며 이후 관리 목적으로 사용됩니다. 따라서 설치하기 전에 SoftGrid Browser Account, SoftGrid Administrators Group, SoftGrid Users Group의 세 가지 그룹 및 계정을 만들어야 합니다.
SoftGrid Browser Account는 Active Directory를 검색하는 데 필요합니다. 따라서 다중 도메인 환경의 모든 Active Directory 도메인에 대한 읽기 전용 권한이 필요합니다. SoftGrid Administrators Group은 SoftGrid 관리 콘솔 및 SoftGrid 관리 웹 서비스에 관리자 액세스 권한을 부여하는 데 사용됩니다. SoftGrid Users Group은 기본 공급자 정책을 할당하는 데 사용됩니다. 이 정책은 도메인의 모든 사용자에게 관리 콘솔을 통해 게시되는 응용 프로그램에 대한 액세스 권한을 부여하는 데 사용됩니다.

가상 환경
SystemGuard는 SoftGrid 클라이언트의 핵심으로, 로컬 데스크톱에서 실행됩니다. SystemGuard는 응용 프로그램이 격리된 상태에서 실행될 수 있도록 모든 기능이 작동하는 가상 환경을 제공하는 데 사용됩니다. 이와 같이 격리된 환경에는 레지스트리, 파일, 글꼴, INI, COM, 포함 서비스, 환경 변수 등 응용 프로그램을 정상적으로 실행하는 데 필요한 가상화된 OS 구성 요소가 들어 있습니다(그림 3).
그림 3 응용 프로그램이 격리된 상태로 실행되는 가상 환경
그림 3 응용 프로그램이 격리된 상태로 실행되는 가상 환경
SystemGuard는 실행할 모든 응용 프로그램에 대해 가상 레지스트리 키를 생성합니다. 이 키는 로컬 OS에서 실행되는 다른 응용 프로그램에서는 액세스할 수 없으며 regedit 등의 레지스트리 편집 도구에도 표시되지 않습니다. 레지스트리 읽기 및 쓰기는 필요에 따라 가상 키로 리디렉션됩니다. 그러나 가상 레지스트리 키에 없는 정보가 필요할 경우 가상 응용 프로그램은 로컬 레지스트리에 연결할 수 있습니다.
이와 비슷하게 SystemGuard는 가상 파일 시스템을 만들어 응용 프로그램 읽기 및 쓰기 작업의 대부분을 이 파일 시스템으로 리디렉션합니다. 이 가상 파일 시스템은 외부와 격리되어 있으며 단일 클라이언트에서 동일한 응용 프로그램의 여러 버전을 실행하려는 경우 필요한 환경을 제공합니다.
그러나 응용 프로그램이 로컬 OS와 격리되어 있더라도 사용자는 인쇄, 잘라내기 및 붙여넣기, 네트워크 드라이브와 같은 모든 로컬 서비스에 액세스할 수 있습니다.

응용 프로그램 패키징
지금쯤이면 가상 응용 프로그램이 실행될 완전한 기능을 갖춘 독립적 환경을 구축하는 방법이 궁금할 것입니다. 이 작업을 위해서는 SoftGrid 시퀀서를 사용합니다. 마법사 방식의 이 도구를 사용하면 클라이언트에 보내서 실행할 수 있는 가상 환경의 응용 프로그램을 패키지로 만들 수 있습니다.
시퀀스 지정 프로세스는 설치, 구성 및 테스트, 실행의 세 가지 단계로 이루어집니다. 첫 번째인 설치 단계에서 SoftGrid 시퀀서는 능동적 감시 프로세스를 통해 응용 프로그램의 설치 과정을 모니터링하고 응용 프로그램 종속성을 평가합니다. 이 작업이 완료되면 구성 및 테스트 단계가 시작되어 첫 실행 환경이 원하는 수준으로 구현될 수 있도록 기본 구성에 필요한 변경이 진행됩니다. 마지막으로 실행 단계에서 SoftGrid 시퀀서는 응용 프로그램 실행에 필요한 코드 블록을 컴파일하고 정렬합니다. FB1(Feature Block 1)은 응용 프로그램 실행에 필요한 필수 코드로, 전체 패키지를 다운로드하지 않고 응용 프로그램을 실행할 수 있게 해 줍니다.
응용 프로그램 시퀀스가 지정되면 가상 응용 프로그램 파일(.sft), Open Software Description 파일(.osd), 아이콘 파일(.ico), 프로젝트 파일(.sprj)의 4개 파일이 생성됩니다. 그런 다음 이 파일이 SVAS의 콘텐츠 디렉터리에 복사됩니다. 또한 관리자가 HTTP 서버를 사용하여 .ico 파일과 .osd 파일을 클라이언트에 게시하는 방법도 있습니다.
SoftGrid는 일반적으로 응용 프로그램이 격리된 환경에서 독립적으로 실행되도록 구축하지만 SystemGuard는 일부 응용 프로그램 간의 상호 작용을 허용합니다. 따라서 응용 프로그램 간의 종속성을 면밀히 검사하여 서로 상호 작용해야 하는 응용 프로그램의 시퀀스를 지정해야 합니다. 일반적으로 이러한 프로세스를 조합(suiting)이라고 합니다. 상호 작용이 필요한 모든 응용 프로그램의 시퀀스를 지정할 수는 없다는 점에 주의해야 합니다. 조합은 매우 복잡한 프로세스이므로 종속성을 면밀히 조사한 후에 수행해야 합니다. 둘 이상의 응용 프로그램 시퀀스를 지정하면 가상화의 이점을 얻기 어려울 수도 있기 때문입니다.

관리 작업 간소화
SoftGrid 관리 콘솔에서는 모든 관리 작업을 수행할 수 있습니다. 관리 콘솔은 기본적으로 SVAS에 설치되며 다른 모든 서버 또는 워크스테이션에도 설치할 수 있습니다. MMC 3.0 스냅인인 관리 콘솔은 SoftGrid 관리 웹 서비스를 사용하여 SoftGrid 데이터 저장소(그림 4 참조)에 연결되므로 권한이 있는 관리자는 데이터베이스에 저장된 데이터에 제한 없이 액세스하여 관리 작업을 수행할 수 있습니다. 관리 콘솔과 SoftGrid 관리 웹 서비스 간의 연결에는 Microsoft .NET Framework 원격 기능이 사용되어, 관리 콘솔과 웹 서비스를 동일한 서버 또는 서로 다른 서버에 설치할 수 있게 해 줍니다. 그림 2에서는 이러한 다양한 구성 요소가 어떻게 결합되며 전체 SoftGrid 구현에 대한 액세스를 제공하는지 보여 줍니다. 규모가 큰 조직에서는 둘 이상의 SoftGrid 관리 웹 서비스 인스턴스를 실행해야 합니다.
그림 4 데이터 저장소에 대한 연결을 제공하는 SoftGrid 관리 웹 서비스
그림 4 데이터 저장소에 대한 연결을 제공하는 SoftGrid 관리 웹 서비스
SoftGrid 관리 웹 서비스는 IIS 5.0 이상이 설치된 Windows 2000 이상에서 실행됩니다. 데이터 저장소에 연결하기 위해서는 .NET Framework 2.0 이상과 Microsoft Data Access Components(MDAC) 2.7 이상이 필요합니다.
관리 콘솔을 사용하면 응용 프로그램 게시 및 종료와 같은 다양한 관리 작업을 수행할 수 있습니다. 그림 5의 메뉴에 표시된 것처럼 작업은 9개의 주요 범주 또는 컨테이너로 분류됩니다.
그림 5 단일 관리 콘솔에서 SoftGrid 관리
그림 5 단일 관리 콘솔에서 SoftGrid 관리
각 컨테이너에 들어 있는 관리 작업 유형을 간략히 정리하면 다음과 같습니다. Applications 컨테이너에서는 관리자가 .sprj 파일을 가져와서 새 응용 프로그램을 게시하고 .osd 위치를 지정하고 응용 프로그램을 제거하는 등의 작업을 수행할 수 있습니다. 기본적으로 이 컨테이너에는 응용 프로그램 서버에 대한 클라이언트 연결을 테스트할 때 사용할 수 있는 게시된 패키지가 들어 있습니다.
응용 프로그램 시퀀스가 지정되면 파일 형식 연결이 만들어집니다. 패키지 가져온 후에는 관리 콘솔에서 해당 파일 형식 연결을 사용할 수 있습니다. File Type Associations 컨테이너에서는 관리자가 모든 파일 형식 연결을 수정할 수 있습니다.
Packages 컨테이너는 패키지의 여러 버전을 관리하여 능동적으로 업그레이드를 수행합니다. 이러한 응용 프로그램 업그레이드는 사용자가 연결을 끊거나 서버를 종료할 필요 없이 수행할 수 있습니다. 또한 관리자는 이 컨테이너를 사용하여 관리 콘솔에서 패키지를 삭제할 수도 있습니다. Packages 컨테이너에서 패키지를 삭제하면 관리 콘솔과 데이터 저장소에서 .sft 파일이 삭제되지만 응용 프로그램 서버의 콘텐츠 디렉터리에서는 .sft 파일이 삭제되지 않습니다.
앞서 설명했듯이 사용자가 응용 프로그램을 실행하면 SoftGrid 클라이언트는 라이선스를 확인하여 데이터 저장소에 사용할 수 있는 라이선스인 경우에만 응용 프로그램을 실행합니다. Application Licenses 컨테이너에서는 관리자가 라이선스와 응용 프로그램을 연결할 수 있습니다. 무제한 라이선스, 동시 사용 라이선스, 명명된 라이선스가 모두 지원됩니다.
Server Groups에는 응용 프로그램 가상화 서버의 논리 그룹과 로깅 정보가 들어 있습니다. 관리자는 새 서버 그룹을 추가하거나 통신에 사용되는 포트 또는 할당된 메모리와 프로세스 등 기존 그룹의 속성을 수정할 수 있습니다.
Provider Policies 컨테이너에서는 정책이라고 부르는 일련의 규칙을 만들 수 있습니다. 사용자 지정 공급자 정책을 사용하면 다양한 조건에 따라 사용자에게 다양한 응용 프로그램에 대한 액세스 권한을 부여할 수 있습니다. Account Authorities 컨테이너에서는 SoftGrid에서 도메인의 디렉터리 정보에 대한 읽기 권한이 필요할 경우 사용되는 도메인 및 자격 증명을 지정할 수 있습니다. SoftGrid Administrators 컨테이너에는 SoftGrid 환경에 대한 관리 권한이 있는 사용자 그룹이 들어 있습니다. 관리자는 이 컨테이너에서 그룹을 추가 또는 제거하여 액세스 권한을 제어할 수 있습니다.
마지막으로 Reports 컨테이너에서는 그 이름으로도 알 수 있듯이 SoftGrid 환경의 전반적 상태를 확인하기 위한 보고서를 작성할 수 있습니다. Application Utilization, Software Audit, System Utilization, User/Group Activity, System Error 등의 보고서를 작성할 수 있습니다.

클라이언트 설정
SoftGrid 클라이언트는 사용자가 가상 응용 프로그램에 액세스하는 데 사용할 컴퓨터의 운영 체제에 설치됩니다. 앞서 살펴보았듯이 Microsoft SoftGrid for Desktops 또는 Microsoft SoftGrid for Terminal Services라는 두 가지 유형의 클라이언트가 지원됩니다. 각 유형마다 고유한 이점을 제공하지만 네트워크 지연, 서버 팜 통합, 관리 용이성 면에서 성능상의 장단점이 있습니다.
데스크톱 구현의 경우 응용 프로그램을 로컬로 사용할 수 있으며 네트워크 가용성과 처리량에는 거의 영향을 받지 않습니다. 이 유형은 예를 들어 지사의 IT 인프라가 제한적인 기업 조직에 적합합니다. 터미널 서비스는 이미 터미널 서버를 구축한 조직에 적합합니다. 이 방식을 사용하면 하드웨어와 소프트웨어를 효율적으로 활용할 수 있으므로 필요한 서버 수를 대폭 줄일 수 있습니다. 또한 이 방식을 사용하면 자유로운 사용자 환경을 구현할 수 있습니다. 대규모 조직에서는 일반적으로 데스크톱과 터미널 서버 인프라가 결합되어 있습니다. SoftGrid 배포를 설정할 때 다양한 구성 요소를 설치 및 구성하는 작업은 두 유형이 서로 비슷합니다.
클라이언트는 수동 설치 또는 Systems Management Server 2003과 같은 도구를 이용한 자동 배포 등 어떠한 표준 방법으로도 배포할 수 있습니다. 그림 6에서는 이러한 클라이언트를 설치하는 데 필요한 하드웨어 및 소프트웨어의 최소 요구 사항을 보여 줍니다.
Figure 6 SoftGrid 클라이언트의 시스템 요구 사항 (Close Figure 6)

클라이언트 | 프로세서 | 메모리 | 디스크 공간 | 운영 체제
Microsoft SoftGrid for Terminal Services | PIII 850MHz | 1GB RAM(최소 256MB, 실제 요구량은 사용자 및 응용 프로그램 수에 따라 다름) | 12MB의 설치 공간 및 4096MB의 캐시 공간 | • Windows 2000 Server 또는 Advanced Server(터미널 서비스 사용) • Windows Server 2003(터미널 서비스 사용)
Microsoft SoftGrid for Desktops | PIII 600MHz | 128MB | 12MB의 설치 공간 및 2048MB의 캐시 공간 | • Windows 2000 Professional 또는 Windows XP • Windows 2000 Server 또는 Windows Server 2003
클라이언트 설치는 간단한 편이지만 설치 위치, 캐시 크기, 가상 드라이브에 사용할 드라이브 문자, 응용 프로그램 데이터 파일의 위치 등 설치 시 반드시 지정해야 하는 몇 가지 속성이 있습니다. 클라이언트 설치가 완료되면 클라이언트 관리 콘솔을 사용하여 몇 가지 설정을 추가로 지정하거나 변경할 수 있습니다.
클라이언트 관리 콘솔을 실행하려면 제어판의 관리 도구에서 SoftGrid Client Management를 실행합니다. 로컬 컴퓨터 연결 또는 원격 컴퓨터 연결을 선택할 수 있습니다.
그림 7에서는 클라이언트 관리 콘솔이 루트 컨테이너와 세 개의 자식 컨테이너로 구성되는 방식을 보여 줍니다. localhost 루트 탭의 SoftGrid에서는 로깅 디렉터리, 응용 프로그램 데이터 디렉터리, 클라이언트 실행 및 디스플레이 설정, 오류 및 정보 메시지 팝업 빈도, 최대 캐시 크기, 가상 드라이브, SoftGrid 서버 연결 해제 시 네트워크 및 연결 옵션, 사용 권한 등 대부분의 기능 매개 변수를 지정할 수 있습니다.
그림 7 클라이언트 관리 콘솔
그림 7 클라이언트 관리 콘솔
Applications 컨테이너에서는 응용 프로그램을 확인하고 변경할 수 있습니다. Applications 컨테이너는 응용 프로그램이 실행 중인지 여부, 응용 프로그램이 캐시에 잠겨 있는지 여부, 로컬 캐시로 스트리밍된 응용 프로그램(.sft 파일) 비율 등 로컬 응용 프로그램에 대한 상태 정보를 제공합니다.
File Type Associations 컨테이너에서는 파일 형식 연결을 확인, 변경 및 제거할 수 있습니다. 자세한 내용은 앞에서 설명한 파일 형식 연결 부분을 참조하십시오.
Desktop Configuration Servers 컨테이너에서는 설치 과정에서 지정한 응용 프로그램 서버 설정을 지정하고 변경하고 수동으로 새로 고칠 수 있습니다. 이 컨테이너에서는 사용자 로그온 시 클라이언트 새로 고침(기본으로 선택되어 있음)을 실행할 것이지 여부를 선택하고 자동 새로 고침 간격을 지정할 수 있습니다.

결론
Microsoft SoftGrid를 사용하여 응용 프로그램을 가상화하면 시스템 안정성을 높이고 관리 작업을 단순화할 수 있습니다. 여러 구성 요소가 상호 작용하는 이 아키텍처는 IT 인프라에 매끄럽게 통합할 수 있습니다.
Microsoft SoftGrid for Desktops는 Microsoft Desktop Optimization Pack의 일부로 Software Assurance 고객에게 제공됩니다. 자세한 내용은 windowsvista.com/optimizeddesktop을 참조하십시오. Microsoft SoftGrid for Terminal Services는 Microsoft 볼륨 라이선스 계약에 따라 엔터프라이즈 고객에게 독립 실행형 클라이언트 액세스 라이선스로 제공됩니다. 평가판을 다운로드하려면 해당 볼륨 라이선스 계정(https://licensing.microsoft.com)에 로그인하여 제품 다운로드에서 Desktop Optimization Pack for SA를 선택하십시오.

Ahmer Sabri는 Microsoft Financial Services Group의 기술 전문가입니다. Ahmer에게 문의 사항이 있으면 ahmers@microsoft.com으로 연락하십시오.
Kedar Shah는 Microsoft Financial Services Group의 기술 전문가입니다. Kedar에게 문의 사항이 있으면 kedars@microsoft.com으로 연락하십시오.


 From The Editor: 동적 시스템 및 인프라 최적화
From The Editor
동적 시스템 및 인프라 최적화
Joshua Trupin

앞으로 수개월 내에 동적 시스템(Dynamic Systems) 및 인프라 최적화(Infrastructure Optimization)라는 Microsoft의 두 가지 IT 전략이 발표될 것입니다. 이 두 가지 이니셔티브는 여러분이 현재 담당하는 IT 관련 업무를 보다 성공적으로 이끌고 향후의 과제에 대비하는 데 도움이 될 것입니다.
동적 시스템 이니셔티브는 기술 혁신의 4가지 핵심 영역을 포괄하는 도구와 응용 프로그램을 위한 프레임워크를 정의하여 미래의 IT 방향을 안내할 것입니다. 동적 환경을 구축하려면 통합 및 가상화되고 프로세스 중심적이며 모델에 기반을 두고 서비스 지향적이며 사용자 중심적인 인프라와 소프트웨어가 필요합니다.
그러나 동적 IT 환경 구축이 Microsoft의 제품에만 국한되는 것은 아닙니다. 조직에서는 급격히 복잡해지는 환경을 관리하는 데 급급하기 보다는 IT를 통해 사업적 우위를 창출하는 데 더 많은 투자를 집중할 수 있습니다. 인프라 최적화 모델을 활용하여 향후 2년간의 조직의 사업 방향을 가늠한다면 현재의 시스템을 최대한 활용하고 더욱 동적인 미래를 계획할 수 있을 것입니다.
대체로 기업의 IT 수명 주기는 다음 4개 단계 중 하나에 위치해 있습니다. 기본 단계: "할 일이 너무 많은 단계", 표준화 단계: "순조롭게 제어되는 단계", 합리화 단계: "비즈니스의 원동력 역할을 하는 단계", 동적 단계: "회사의 전략적 자산으로 자리잡은 단계". 각 단계에 대한 자세한 내용은 microsoft.com/io에서 볼 수 있습니다. 여기에서 제시하는 지침을 활용하여 조직의 인프라를 분석하고 미래에 대비한 계획을 수립할 수 있습니다. 동적 시스템 개념을 적용하면 IT 조직을 비즈니스의 핵심 자산으로 활용할 수 있습니다.
동적 단계에 도달하면 조직의 IT 시스템은 자체적으로 관리가 가능한 전략적 비즈니스 자산이 될 것입니다. 이것이야말로 IT가 추구해야 할 경지라 할 수 있을 것입니다. IT 관리 솔루션인 System Center 제품군은 동적 IT를 위한 여정을 단계적으로 밟아 나가는 최선의 방법입니다. System Center에서는 구성 도구, 배포 응용 프로그램, 운영 관리자 등을 비롯한 다양한 도구를 제공하며 계획, 배포, 유지 관리 등 IT 수명 주기의 모든 과정을 포괄합니다.
물론 TechNet Magazine이 여러분의 발전을 지원할 것입니다. 이번 호에서는 System Center 제품군에 초점을 맞추어 두 가지 핵심 구성 요소인 System Center Configuration Manager 2007과 System Center Operations Manager 2007에 대한 개요를 시작으로 배포와 운영, 나아가 성공적인 지사 관리까지 다루고 있습니다.
조직의 인프라가 어느 정도 수준입니까? TechNet Magazine 블로그(blogs.technet.com/tnmag)를 방문하여 동적 IT에 대한 여러분의 의견을 알려 주시기 바랍니다. —Joshua Trupin

Joshua Trupin


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

부팅 구성 데이터 관리
VistaBootPRO
www.vistabootpro.org
필자가 아는 IT 전문가들은 모두 멀티 부팅 시스템을 한두 대 이상 가지고 있습니다. 현재 이러한 시스템에는 주로 Windows Vista® 또는 Windows Server® 2008(이전 코드 이름 "Longhorn") 인스턴스가 포함되어 있습니다. 이러한 운영 체제에서 멀티 부팅 시스템을 실행한다면 PROnetworks의 VistaBootPRO를 확인해 보십시오.
알고 계실지 모르지만 Microsoft는 Windows Vista를 시작으로 부팅 구성 관리 방식을 바꾸었습니다. 이제 Boot.ini와 같이 읽기 쉬운 텍스트 파일 대신 BCD(부팅 구성 데이터) 저장소를 사용합니다. BCD(부팅 구성 데이터)는 펌웨어에 관계없이 보다 안전하게 부팅 환경 세부 사항을 관리할 수 있는 방법입니다. BCD를 확인 및 수정하는 기본 방법에는 세 가지가 있습니다. 첫 번째 방법은 MSConfig를 사용하는 것입니다. MSConfig는 BCD의 항목을 읽고 수정하고 순서를 변경할 수 있는 기본적인 방법입니다. 명령줄 도구인 BCDEdit을 사용하는 두 번째 방법은 아마도 시스템 관리자에게 가장 친숙한 방법일 것입니다. 이 도구를 사용하면 새로운 BCD 저장소를 생성하고 기존 저장소를 수정할 수 있으며 보관 및 재사용을 위해 저장소를 가져오거나 내보낼 수 있습니다. 세 번째 방법은 Windows® Management Instrumentation(WMI) API를 사용하여 프로그래밍 방식으로 BCD를 관리하는 것입니다.
이 세 가지 방법 모두 작업을 완료하는 데는 문제가 없지만 그다지 사용하기 편리한 방법은 아닙니다. 바로 이 때문에 VistaBootPRO가 필요한 것입니다. VistaBootPRO에서는 보다 친숙한 GUI를 사용하여 Windows Vista를 실행하는 시스템에서 부팅 구성을 수정할 수 있습니다. 이 도구를 사용하면 OS 항목 이름 변경, 새 항목 추가, 부팅 드라이브 변경, 시간 제한 옵션 구성 등을 한두 번의 클릭만으로 간편하게 수행할 수 있습니다. 뿐만 아니라 OS 항목을 선택한 후 이 OS에서 사용 가능한 CPU를 제한하거나, Windows Vista나 Windows Server 2008 항목에 대한 DEP(데이터 실행 방지)를 설정 또는 해제하거나, OS에서 사용할 수 있는 실제 메모리를 줄이거나 부팅 프로세스를 디버그 모드로 실행하는 등과 같은 시작 매개 변수를 설정할 수 있습니다.
이 도구를 사용하여 BCD를 변경하려면 먼저 작업이 잘못될 경우에 대비하여 현재 저장소를 백업해야 합니다. 이 응용 프로그램은 사용자가 백업을 생성하지 않은 경우 경고 메시지를 표시하고 현재 구성을 쉽게 내보낼 수 있는 방법을 제공합니다. 물론 백업된 구성은 VistaBootPRO를 사용하여 복원할 수 있습니다.
한마디로 VistaBootPRO는 사용이 간편하고 유용한 기능이 많은 BCD 관리 응용 프로그램입니다. 무엇보다도 무료로 제공된다는 것이 가장 큰 장점입니다.

가격: 무료.
VistaBootPRO 실행 화면
VistaBootPRO 실행 화면

서비스 및 장치 모니터링
NetGong
netgong.tsarfin.com
사람들은 항상 더 나은 모니터링 도구를 원하게 마련입니다. 새로운 네트워크 서비스 및 장치 모니터를 찾고 있거나 단순히 모니터링 유틸리티에 관심이 있는 분들은 NetGong이란 제품을 확인해 보시기 바랍니다.
이 응용 프로그램은 시스템 트레이에서 실행되며 Windows가 시작될 때 실행됩니다. 아이콘을 마우스 오른쪽 단추로 클릭하면 모니터링 시작 또는 중단 옵션을 쉽게 선택할 수 있습니다. 그리고 아이콘을 두 번 클릭하면 기본 구성 UI가 나타나는데 여기서 모니터링 대상 호스트의 이벤트를 설정, 검토 및 확인할 수 있습니다.
호스트 모니터 설정은 간단합니다. 호스트, 모니터링하려는 TCP 포트, 테스트 실행 간격 및 받길 원하는 경고 유형만 입력하면 됩니다. 또한 의미 있는 설명을 추가하거나 시간 제한, 패킷 크기, 재시도 횟수 등의 기본 ICMP(Internet Control Message Protocol) 설정을 변경할 수도 있습니다. 기본적으로 NetGong에서는 모니터링 대상 호스트가 ICMP 요청에 응답해야 합니다. 그러나 네트워크에서 ICMP 요청을 수락하지 않는 자동 호스트의 확인란을 사용하여 이 옵션을 무시할 수도 있습니다.
이 응용 프로그램은 사운드, 전자 메일, 메시지, 파일의 네 가지 경고 범주를 제공합니다. 사운드의 경우 원하는 WAV 파일을 지정할 수 있습니다. 메시지 경고에서는 텍스트 메시지를 정의하고 이 메시지가 최상단 창에 나타나도록 지정할 수 있으며 창 닫기를 자동 또는 수동으로 선택할 수 있습니다. 전자 메일 경고의 경우 SMTP 서버와 전송할 메시지의 세부 내용을 지정할 수 있습니다. 그리고 파일 경고 옵션을 사용하면 구성 가능한 매개 변수, 창 모드 및 시작 디렉터리로 실행 파일(또는 배치 파일)을 실행할 수 있습니다. 각각의 경고 유형마다 첫 번째 경고 전송 시간을 지정한 일정, 전송할 최대 경고 수, 그리고 경고 간 작업 실패 간격(작업 실패 횟수)을 구성할 수 있습니다. 또한 서비스가 복구되면 알림을 받도록 선택할 수도 있습니다.
NetGong도 결과 로그 파일을 보관합니다. 이벤트 로그, 텍스트 파일 또는 동적으로 생성된 HTML 페이지에 이벤트를 기록할 수 있습니다. 이 응용 프로그램을 사용하면 사용자 지정 포트를 수신하는 기본 제공 웹 서버가 제공하는 페이지에서 모니터링 결과를 볼 수 있습니다. 또한 새로 고침 간격이 포함된 쿼리 문자열 매개 변수를 전송하여 웹 페이지에 최신 모니터링 이벤트 세부 사항이 반영되도록 할 수 있습니다.

가격: 기업용 라이선스의 경우 시스템당 79.95달러, 교육 기관용 라이선스의 경우 시스템당 59.95달러, 가정용 라이선스의 경우 시스템당 39.95달러
steen.toolbox.netgong 실행 화면
steen.toolbox.netgong 실행 화면

서평
Windows PowerShell: TFM
www.sapienpress.com
Windows PowerShell™은 물론 이미 들어 보셨겠지요? 지금 많은 사람들이 Windows PowerShell™에 열광하고 있는 것 같습니다. TechNet Magazine에는 Windows PowerShell™만을 다룬 칼럼(이 책의 저자 중 한 명이 작성)이 실렸을 정도입니다. 그런데 직접 Windows PowerShell™ 책을 탐독한 적이 있으십니까?
Windows PowerShell은 일단 사용 방법에 익숙해지면 놀랄 만큼 뛰어난 효과를 얻을 수 있는 자동화 및 생산성 도구입니다. 스크립팅에 익숙해지기 시작한 사람이나 이미 VBScript에 통달하여 이 새로운 관리자 중심의 스크립트 언어와 명령줄 도구 집합을 배워보려는 사람들은 Windows PowerShell: TFM(저자: Don Jones 및 Jeffery Hicks)부터 읽어보는 것이 좋습니다. 이해하기 쉽게 구성된 이 책은 시스템 관리자를 주요 대상으로 하며 대부분의 관리자에게 유용한 기능들을 중점적으로 다룹니다.
책의 첫 번째 단원은 Windows PowerShell 환경을 소개하면서 모든 cmdlet이 공통으로 갖는 매개 변수와 스크립트 언어의 기본 구문 및 문법을 다룹니다. 또한 리디렉션, 실행 파이프라인, 함수, 변수 및 복수 셸 실행의 개념도 나와 있습니다. Windows PowerShell은 Microsoft® .NET Framework에 기반을 두기 때문에 관리 코드의 이점을 그대로 포함하고 있습니다. 단, Windows PowerShell에는 .NET Framework 2.0 이상이 필요합니다. 뿐만 아니라 이 책을 읽으면 스크립트가 실행되는 보안 컨텍스트부터 리플렉션, 어셈블리 및 클래스의 개념에 이르기까지 Framework의 필수 사항에 대해 확실하게 파악할 수 있습니다.
저자는 Windows PowerShell을 WMI(Windows Management Instrumentation)에 연결하는 방법을 설명한 후 Windows PowerShell 스크립트 언어 구조를 자세히 다루면서 개체의 함수와 관련 속성 및 메서드를 이해하는 데 유용한 예제도 제공합니다. 이 책에서는 또한 강력한 정규식은 물론 기본 산술 연산자부터 비트 단위의 비교 연산자에 이르기까지 다양한 종류의 연산자를 사용하여 IP 주소 및 도메인 컨트롤러 이름과 같은 항목의 문자열을 구문 분석하는 방법도 배울 수 있습니다. 이 책은 특히 Windows PowerShell을 마스터하려는 사람들에게 매우 훌륭한 기반 지식을 제공할 것입니다.
데이터베이스 스크립트 및 Windows 관리에 관한 장에서는 Windows PowerShell이 제공하는 몇 가지 고급 기능에 대해 설명합니다. 여기서 이벤트 로그, 프로세스, 레지스트리, 파일 시스템 및 디렉터리 서비스를 사용하는 방법과 데이터베이스에서 쿼리를 연결 및 실행하는 방법도 알 수 있습니다.
그밖에 다른 단원에서는 데이터 출력 및 서식 지정, 스크립트 모듈화, 오류 처리, 디버깅 등을 다룹니다. 이 책은 심지어 명명 규칙, 코드 주석, 코드 가독성 향상을 위한 공백 사용 등을 포함하여 Windows PowerShell 스크립트를 작성하는 최선의 방법까지 제안하고 있습니다.
이 책을 늘 가까이 두고 필요할 때마다 부록의 자료들을 참고하면 좋습니다. 부록에서는 133개의 Windows PowerShell cmdlet 전체를 참조할 수 있을 뿐만 아니라 가장 자주 사용되는 유형 및 이러한 유형과 관련된 속성과 메서드도 참조할 수 있습니다. 이러한 참조 자료는 특정 cmdlet의 사용 방법을 간단히 보여 주기도 하지만 Windows PowerShell이 제공하는 광범위한 기능도 요약하여 보여 줍니다.

가격: 정가 49.99달러

케이블 테스트
SMARTest Compact Network Cable Tester
www.hobbes-usa.com
요즘은 어디에나 케이블이 널려 있습니다. IT 전문가들은 대부분 CAT5 케이블로 둘러싸여 있습니다. 수백 개의 CAT5 케이블이 수십 킬로미터나 뻗어 있습니다. 이러한 케이블을 책임지고 있는 사람에게는 강력하고 휴대하기 편한 케이블 테스트 제품이 필수입니다. 바로 이 때문에 Hobbes의 SMARTest Compact Network Cable Tester를 살펴볼 필요가 있습니다.
이 SMARTest 장치는 펜 스타일의 케이블 테스트 장치로, CAT 3, 4, 5, 5e, 6 네트워크 케이블과 호환되며 일반적인 케이블 문제를 찾아냅니다. 특히 케이블 내에서 단선, 단락, 역방향, 선 바뀜, 분리된 쌍, 접지 등의 문제를 확인할 수 있습니다.
이 장치는 네 개의 작은 시계 스타일의 배터리로 작동하기 때문에 테스트를 위해 케이블을 연결할 필요가 없고 SMARTest를 활성 네트워크에 연결할 필요도 없습니다. 케이블을 테스트하려면 케이블 한쪽을 본체에 연결하고 다른 한쪽을 분리 가능한 원격 장치에 연결하기만 하면 됩니다. 이 SMARTest 장치는 RJ45 소켓 및 플러그(암/수) 커넥터 모두와 인터페이스로 연결되기 때문에 모든 종류의 케이블 설정을 테스트할 수 있습니다. 심지어 SMARTest 장치로 배선이나 배선반 및 콘센트를 검사할 수도 있습니다.
이 밖에도 장치에 톤 생성 기능이 기본적으로 내장되어 있기 때문에 테스트 중인 케이블을 통해 오디오 신호를 보낼 수 있습니다. 그런 다음 Hobbes의 Cable Tracer Probe와 같이 호환되는 신호 검색 장치로 이러한 신호를 받으면 됩니다.
톤 생성 기능이 포함된 이 SMARTest는 소매업자에 따라 약 80~90달러에 판매됩니다. 동축 케이블 테스트를 위한 F 커넥터 어댑터가 선택 사항으로 제공됩니다.

가격: 정가 99.99달러
steen.toolbox.smartest 사진

Greg Steen은 사업가이자 열성적인 기술 전문가로, IT 전문가의 개발 및 운영 작업에 유용한 새로운 도구와 방법을 끊임없이 연구하고 있습니다.


 SQL Q&amp;A: 잠금 검색, 대용량 쿼리, I/O 통계 및 기타
SQL Q&A
잠금 검색, 대용량 쿼리, I/O 통계 및 기타
편집자: Nancy Michell
이 기사의 코드 다운로드: SQLQandA2007_08.exe (151KB)

Q: 모든 데이터베이스에서 잠금이 설정된 개체 이름을 확인해야 합니다. 어떻게 해야 합니까?

A: SQL Server™ 2000의 경우 아래와 같이 master에서 syslocks 시스템 테이블을 쿼리하거나 sp_lock을 실행하여 현재 잠금 정보를 가져올 수 있습니다.
SELECT * FROM master..syslocks
EXEC sp_lock
그러나 sp_lock 저장 프로시저의 OUTPUT에 있는 ObjID(또는 master..syslocks의 id 열)에서 실제 개체인 NAMES를 변환해야 할 경우가 있습니다.
SQL Server 2005 SP1 및 이전 버전에서는 OBJECT_NAME 함수를 사용하여 object_id 매개 변수 한 개만 전달할 수 있습니다. 따라서 개체 이름을 제대로 가져오려면 OBJECT_NAME을 실행하기 전에 현재 데이터베이스에서 작업을 수행해야 합니다. 이렇게 하면 정확한 OBJECT_NAME을 가져오기 위해 각 데이터베이스마다 루프를 실행하는 사용자 지정 코드를 작성해야 하기 때문에 현재 잠금을 모니터링하기가 어려워집니다.
USE DBNAME
SELECT OBJECT_NAME(object_id)
SQL Server 2005 SP2에서는 두 번째 매개 변수 database_id를 추가하여 이런 문제점을 개선했습니다. 이 새로운 매개 변수를 사용하면 현재 연결된 데이터베이스에 상관없이 개체 이름을 쿼리할 수 있습니다.
OBJECT_NAME ( object_id [, database_id ] )
이제 다음과 같이 sys.dm_tran_locks를 쿼리하고 각 데이터베이스의 개체 이름을 검색할 수 있습니다.
SELECT
DB_NAME(resource_database_id),
OBJECT_NAME(resource_associated_entity_id, resource_database_id)
FROM sys.dm_tran_locks
WHERE resource_type='OBJECT'
단, 이 매개 변수는 SQL Server 2005 SP2 및 이후 버전에만 적용됩니다. SQL Server 2005 이전 버전에서 이 기능을 실행하면 다음과 같은 오류 메시지가 나타납니다.
Msg 174, Level 15, State 1, Line 1
The object_name function requires 1 argument(s).
그림 1에 나온 다른 예는 sys.dm_exec_sessions를 결합하여 잠금과 연관된 서비스 프로세스 ID(SPIDS)에 관한 정보를 가져옵니다. 자세한 내용은 SQL Server 온라인 설명서(technet.microsoft.com/library/ms130214(sql.90).aspx)를 참조하십시오.
Figure 1 서버 프로세스 ID 검색 (Close Figure 1)
SELECT
DB_NAME(resource_database_id) as DBName,
OBJECT_NAME(resource_associated_entity_id, resource_database_id) AS ObjectName,
request_mode,
request_type,
request_session_id,
es.host_name,
es.login_name,
es.login_time
FROM
sys.dm_tran_locks tl
INNER JOIN sys.dm_exec_sessions es
ON tl.request_session_id=es.session_id
WHERE resource_type='OBJECT'

Q: 대용량 동적 SQL 쿼리가 가끔 NVARCHAR(max) 길이를 초과하는 것 같습니다. 이 문제를 피해 하나의 큰 문자열을 실행할 수 있는 방법이 있습니까?

A: 쿼리가 NVARCHAR(max) 길이를 초과한다면 2GB 쿼리인 것입니다. 연결된 모든 문자열을 NVARCHAR(max)로 변환해야 할 수도 있습니다. 그러나 SQL Server 2005 이전 버전에서도 효과적으로 사용할 수 있는 보다 편리한 방법은 여러 개의 작은 문자열을 함께 연결하는 것입니다. 예를 들면 다음과 같습니다.
DECLARE @q1 NVARCHAR(4000), @q2 NVARCHAR(4000), @q3 NVARCHAR(4000)
SET @q1 = 'SELECT...'
SET @q2 = 'FROM...'
SET @q3 = 'WHERE...'
EXEC (@q1 + @q2 + @q3)
팁: OUTPUT 절 사용
이제 트리거를 사용하지 않고도 DML(데이터 조작 언어) 문을 사용하여 수행된 변경 내용을 감사할 수 있습니다. SQL Server 2005에서는 OUTPUT 절이 DML 문의 일부로 도입되어 모든 DML 작업에서 수행된 변경 내용을 추적하는 데 유용하게 사용될 수 있습니다. 이 OUTPUT 절은 결과 집합을 테이블 또는 테이블 변수에 저장할 수 있습니다.
이 기능은 INSERTED 및 DELETED 테이블에서 트리거가 했던 역할과 비슷합니다. 즉, DML 작업 도중 수정된 행을 액세스하는 것입니다. 이 기능이 어떻게 작동하는지 보기 위해 아래 그림과 같이 주소 테이블의 주소를 원래 값과 반대되는 값으로 변경해 보겠습니다. 이 코드에 표시된 논리를 사용하면 데이터의 모든 변경 내용을 추적하여 테이블에 저장할 수도 있습니다.
쿼리 결과는 다음과 같이 나타납니다.
Original Value:'1234 One Microsoft Way, Redmond, Wa.' has been changed to: '.aW,dnomdeR
,yaW tfosorciM enO 4321'

주소 변경
--Create the address table
Create Table Address (ProductID Int, SupplierID Int, Address Varchar(255))

--Insert data
Insert into Address Values (234,567,'1234 One Microsoft Way, Redmond, Wa.')

--Declare a table variable
Declare @Recordchanges table (change Varchar(255))

--Update the address
Update Supplier.Address
Set Address=reverse(address)

--Record the updates into the table variable
OUTPUT 'Original Value:' + DELETED.Address+' has been changed to: '+ INSERTED.Address+''
into @RecordChanges

--Query the changes from table variable
Select * from @RecordChanges

Q: 현재 Windows Server® 2003에 업무에 중요한 SQL Server 2005 클러스터가 설치되어 있습니다. Microsoft® DTC(Distributed Transaction Coordinator)가 클러스터 쿼럼과 함께 동일한 그룹에 "클러스터"되었지만 전용 디스크 리소스를 사용합니다. 다시 말해 MS DTC가 클러스터 쿼럼 그룹과 동일한 네트워크 이름 및 IP 주소를 사용합니다. 이 구성을 Microsoft가 제공하는 최선의 방법에 따라 수정하려고 합니다. 따라서 MS DTC를 전용 클러스터 그룹으로 이동하는 것과 관련하여 조언이 필요합니다. Cluster Admin Tool을 사용하여 MS DTC 서비스를 제거한 후 전용 그룹에서 다시 생성하면 충분할까요?

A: MS DTC를 위한 전용 디스크 리소스가 이미 있기 때문에 리소스를 제거한 후 새 그룹에서 다시 생성하기만 하면 됩니다. 새 그룹에서는 네트워크 이름과 가상 IP 주소도 새로 만들어야 합니다.
또는 클러스터 그룹에서 새 네트워크 이름과 IP 주소를 생성하고 새 리소스에 대한 종속성을 변경할 수도 있습니다. 그런 다음 MS DTC를 새 그룹으로 끌어오면 전용 디스크와 새 리소스도 함께 옮겨집니다.

Q: 데이터베이스에서 물리적 데이터베이스 파일에 대한 I/O 통계를 확인해야 합니다. 어떻게 하면 됩니까?

A: SQL Server 2000 및 SQL Server 2005 모두에서 지원되는 시스템 함수 fn_virtualfilestats나 SQL Server 2005에서만 지원되는 sys.dm_io_virtual_file_stats 함수를 사용하면 됩니다. 이 함수는 SQL Server의 인스턴스가 마지막으로 시작된 이후 수집된 통계 정보를 반환합니다. 그림 2에 결과 예가 나와 있습니다.
Figure 2 데이터베이스의 I/O 통계 보기 (Close Figure 2)

DbId | FileId | TimeStamp | NumberReads | NumberWrites | BytesRead | BytesWritten | IoStallMS
20 | 1 | 250765718 | 381 | 0 | 3350528 | 0 | 951
20 | 2 | 250765718 | 12 | 8 | 409600 | 491520 | 0
20 | 3 | 250765718 | 5 | 0 | 40960 | 0 | 16
기본 데이터 파일에 I/O가 미치는 영향을 제대로 이해하면 데이터 볼륨에 파일 및 파일 그룹을 물리적으로 배치하고, 가능한 I/O 병목 현상을 감지하고, 파일 수준의 데이터베이스 유지 관리 작업을 수행하는 등의 작업을 보다 효과적으로 계획할 수 있습니다. 이 함수는 파일과 파일 그룹이 많은 대용량 데이터베이스에서 I/O가 미치는 영향을 검사할 때 특히 유용합니다.
SQL Server 2000에 대한 파일 I/O 정보를 표시하는 쿼리는 다음과 같습니다.
SELECT *
FROM ::fn_virtualfilestats(default,default)
GO
특정 databaseID를 확인하려면 다음과 같이 해당 데이터베이스에 대한 ID를 전달해야 합니다.
SELECT *
FROM ::fn_virtualfilestats(7,default)
GO
서버의 모든 데이터베이스에 대한 파일 통계를 보여 주는 SQL Server 2005 코드는 다음과 같습니다.
SELECT *
FROM ::fn_virtualfilestats(NULL,NULL)
GO
다음 쿼리는 현재 데이터베이스에 대한 파일 통계만 반환합니다.
SELECT *
FROM ::fn_virtualfilestats(NULL,NULL)
WHERE DBID=db_id()
GO
SQL Server 2005의 경우 sys.dm_io_virtual_file_stats라는 새 시스템 함수도 있는데, 이 함수의 역할은 레거시 함수 fn_virtualfilestats를 교체하는 것입니다.
sys.dm_io_virtual_file_stats(
{ database_id | NULL },
{ file_id | NULL }
)
이 함수를 사용하는 방법은 다음과 같습니다.
SELECT * FROM sys.dm_io_virtual_file_stats(NULL,NULL)
출력 결과를 사용하여 실제 데이터베이스 이름과 파일 이름을 보여 주는 보다 읽기 쉬운 보고서를 작성하려면 SQL Server 2000 또는 SQL Server 2005에서 사용할 수 있는 다운로드로 제공되는 코드를 사용하십시오. 이 코드는 TechNet Magazine 웹 사이트에서 확인할 수 있습니다.

Q: 삭제 트랜잭션이 트리거를 발생시켰는지 쉽게 확인할 수 있는 방법을 알고 싶습니다. 이런 정보를 얻는 방법이 있을까요?

A: 삭제, 삽입 및 업데이트 작업을 처리하는 트리거를 다룰 때는 보통 여러 가지 기법을 사용하여 삭제 트랜잭션이 트리거를 발생시켰는지 확인합니다. 가장 많이 사용되는 방법은 삽입 및 삭제된 가상 테이블의 수를 비교하여 일치하는지 확인하는 것입니다. 그러나 이보다 간단한 방법이 있습니다. 바로 Columns_Updated 함수를 사용하는 것입니다.
삭제 트랜잭션이 트리거를 발생시키면 Columns_Updated는 항상 varbinary 값 0x를 반환합니다. 아래를 확인하면 삭제 트랜잭션이 트리거를 발생시켰음을 알 수 있습니다.
IF Columns_Updated() = 0x
팁: 데이터 및 로그 파일 초기화
이전에 삭제한 파일로부터 디스크에 남아 있는 기존 데이터를 덮어쓰기 위해 데이터 및 로그 파일이 초기화되는 것을 알고 계십니까? 데이터 및 로그 파일은 데이터베이스를 생성하거나, 기존 데이터베이스에 파일이나 로그 또는 데이터를 추가하거나, 기존 파일의 크기를 늘리거나(자동 증가 작업 포함), 데이터베이스 또는 파일 그룹을 복원할 때 파일을 0으로 채움으로써 처음 초기화됩니다. 파일을 초기화하면 이러한 작업이 더 오래 걸립니다. 그러나 데이터가 파일에 처음 기록될 때 운영 체제는 파일을 0으로 채울 필요가 없습니다.
SQL Server 2005에서는 데이터 파일을 즉각 초기화할 수 있습니다. 이 기능을 사용하면 앞서 언급한 파일 작업을 훨씬 신속하게 실행할 수 있을 뿐만 아니라 사용된 디스크 공간을 0으로 채우지 않고도 공간을 회수할 수 있습니다. 대신 새 데이터가 파일에 기록되면서 디스크 콘텐츠를 덮어쓰게 됩니다. 로그 파일은 즉각 초기화할 수 없습니다. 즉각적 파일 초기화 기능은 Windows XP Professional과 Windows Server 2003 및 이후 버전에서만 지원됩니다.
삭제된 디스크 콘텐츠는 파일에 새 데이터가 기록될 때만 덮어쓰게 되므로 권한이 없는 사용자가 이 삭제된 콘텐츠를 액세스할 수 있습니다. 데이터베이스 파일이 SQL Server 인스턴스에 연결되어 있는 동안에는 파일의 DACL(임의 액세스 제어 목록)을 통해 이러한 정보 노출 위험을 줄일 수 있습니다. 이 DACL을 사용하면 SQL Server 서비스 계정 및 로컬 관리자만 파일을 액세스할 수 있습니다. 그러나 파일이 분리되면 SE_MANAGE_VOLUME_NAME이 없는 사용자나 서비스가 파일을 액세스할 수 있습니다. 데이터베이스를 백업할 때도 이와 비슷한 위험이 존재합니다. 적절한 DACL로 백업 파일을 보호하지 않으면 권한이 없는 사용자나 서비스가 삭제된 콘텐츠를 무단으로 액세스할 수 있습니다.
삭제된 콘텐츠의 노출 위험이 걱정된다면 분리된 모든 데이터 파일과 백업 파일에 제한적인 DACL이 포함되도록 항상 주의해야 합니다. 또한 SQL Server 서비스 계정에서 SE_MANAGE_VOLUME_NAME을 취소하여 SQL Server 인스턴스에 대한 즉각적인 파일 초기화 기능을 해제해야 합니다.

Thanks to the following Microsoft IT pros for their technical expertise: Christian Bolton, Dan Carollo, Robert Davis, Jorge Guzman, Saleem Hakani, Ward Pond, Kalyan Yella, and Paolo Zavatarelli.


 Utility Spotlight: BGInfo
Utility Spotlight
BGInfo
Lance Whitney
이 기사의 코드 다운로드: BgInfo v4.10 (274KB)

사용자의 PC에서 발생한 문제를 해결하는 데 컴퓨터 이름, IP 주소, 게이트웨이, 메모리, 사용 가능한 디스크 공간 등의 정보가 필요하다고 가정해 보십시오. 이러한 데이터를 모두 수집하려면 여러 출처를 살펴보거나 사용자에게 수많은 질문을 던져야 합니다. 이런 경우에 필요한 PC 관련 정보를 한곳에서 모두 확인할 수 있다면 편리하지 않을까요? Sysinternals에서 무료로 제공하는 BGInfo라는 도구를 사용하면 이러한 꿈이 현실이 됩니다.
Bryce Cogswell이 개발한 BGInfo(Background Information의 약식 표기)는 Windows® 워크스테이션 또는 서버에 네트워크 관련 정보(IP 주소, 라우터, 도메인 이름, MAC 주소)에서 하드웨어 및 소프트웨어 정보(컴퓨터 이름, 메모리, OS 버전 및 서비스 팩 수준)에 이르기까지 주요 데이터를 쿼리합니다. 그런 다음 수집된 모든 데이터를 방해가 되지 않으면서 보기 쉽도록 바탕 화면에 배경 무늬의 일부로 표시합니다(그림 1 참조).
그림 1 바탕 화면에 시스템 정보를 표시하는 BGInfo
그림 1 바탕 화면에 시스템 정보를 표시하는 BGInfo
BGInfo는 설치할 필요 없이 bginfo.exe 파일만 두 번 클릭하면 실행됩니다. 파일을 실행하면 사용자가 표시할 필드를 검토하여 선택할 수 있는 구성 화면이 나타납니다. 기본적으로 BGInfo는 24가지 정보를 제공합니다. 표시하지 않을 필드는 제거할 수 있으며 나중에 필요할 때 다시 추가할 수 있습니다. 또한 손쉽게 추가 필드를 만들 수도 있습니다. BGInfo는 모든 환경 변수, 거의 모든 레지스트리 값, 그리고 VBScript 및 WMI(Windows Management Instrumentation) 쿼리의 출력 결과를 표시합니다. WMI 인터페이스를 사용하면 드롭다운 메뉴에서 값을 선택하는 방법으로 간단히 쿼리를 작성할 수 있습니다. 특정 파일을 대상으로 BGInfo를 사용하여 파일의 버전 정보, 타임스탬프 및 내용을 표시할 수도 있습니다.
표시 방법은 자유롭게 사용자 지정할 수 있습니다. 맞춤, 글꼴의 종류와 크기, 색 등 다양한 텍스트 특성을 변경할 수 있을 뿐만 아니라, 바탕 화면에서 데이터를 여러 위치로 이동할 수 있고, 표시 영역의 최대 너비를 인치 단위로 지정할 수도 있습니다. 마지막으로 BGInfo는 회사 로고와 같은 이미지를 표시할 수 있도록 텍스트 데이터에 그래픽을 추가하는 기능도 지원합니다. 반대로, 이러한 모든 정보를 바탕 화면에 표시하지 않으려면 BGInfo를 시스템 트레이 아이콘으로 설정하면 됩니다. 이 경우 아이콘을 클릭하면 원래 크기로 표시됩니다.
표시 방법을 모두 지정한 후에는 Preview 단추를 클릭하여 표시되는 상태를 미리 확인할 수 있습니다. 그런 다음 마음에 든다면 적용하면 됩니다. 필요할 때마다 BGInfo를 수동으로 실행하거나 자동으로 BGInfo가 업데이트되도록 설정할 수도 있습니다. 주기적으로 데이터를 새로 고치려면 시작 폴더에 BGInfo.exe 파일을 추가하거나 예약된 작업으로 설정하면 됩니다. 특정 컴퓨터에서 BGInfo를 사용자 지정한 후 다른 PC에서도 동일한 설정을 사용해야 하는 경우가 있을 것입니다. 이 경우에는 설정을 BGI 파일로 저장한 다음, 이 프로그램을 실행하는 다른 컴퓨터에서 로드하면 됩니다.
한 번에 한 대의 PC에서 BGInfo를 실행하는 대신, 여러 네트워크 클라이언트에서 동시에 실행해야 할 경우도 있습니다. 이 경우에는 로그인 스크립트에 bginfo.exe 파일을 삽입하면 됩니다. BGInfo는 동작을 제어할 수 있는 몇 가지 명령줄 옵션을 제공합니다. BGInfo에서 수집한 데이터를 텍스트 파일, Excel® 스프레드시트, Access™ 데이터베이스, SQL 데이터베이스 등의 외부 파일로 내보내 모든 네트워크 PC 통계에 대한 리소스로 간편하게 활용할 수도 있습니다.
BGInfo에는 사용 방법을 매우 쉽게 안내하는 도움말 정보가 포함되어 있습니다. 이 도움말에서는 BGInfo에서 출력을 캡처할 수 있는 간단한 VBScript 및 WMI 쿼리 작성 방법도 제공합니다. 이 프로그램은 Windows 95에서 Windows Vista®에 이르는 모든 Windows 버전에서 실행됩니다. BGInfo에 대한 자세한 내용을 확인하고 이 도구를 다운로드하려면 microsoft.com/technet/sysinternals/Miscellaneous/BgInfo.mspx를 참조하시기 바랍니다.

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


 The Cable Guy: Windows Vista의 IPv6 자동 구성
The Cable Guy
Windows Vista의 IPv6 자동 구성
Joseph Davies

IPv6은 IPv4의 32비트 주소 공간을 128비트로 확장한다는 것 외에 다른 면에서도 의의가 있습니다. IPv6 호스트는 DHCPv6(IPv6용 DHCP)과 같은 주소 구성 프로토콜을 사용하지 않고도 자동으로 구성됩니다.
모든 IPv6 노드는 RFC 2462를 기반으로 각 인터페이스의 링크-로컬 주소를 자동으로 구성합니다. 또한 IPv6 호스트는 라우터 요청 및 라우터 알림 메시지를 교환하는 라우터 검색 기능을 사용하여 추가 주소와 구성 설정을 확인합니다. 라우터가 보내는 라우터 알림 메시지에는 호스트가 DHCPv6을 추가 주소나 구성 설정에 사용해야 할지를 나타내는 관리된 주소 구성(M) 및 기타 상태 저장 구성(O) 플래그가 포함됩니다.

IPv6 자동 구성 유형
링크-로컬 주소 외에도 호스트는 라우터 알림 메시지 수신 여부에 따라 상태 비저장 자동 구성을 사용하여 주소와 기타 설정을 구성할 수 있습니다. 이러한 메시지에는 메시지를 수신하는 호스트가 상태 비저장 주소를 얻는 데 사용할 수 있는 하나 이상의 접두사 정보 옵션이 포함될 수 있습니다.
마찬가지로 상태 저장 자동 구성은 DHCPv6을 사용하여 주소를 가져오는지 여부에 따라 주소 및 기타 설정이 구성되는 방식을 말합니다. 이러한 상태 저장 자동 구성은 호스트가 M 플래그가 1로 설정된 라우터 알림 메시지를 수신할 때 사용됩니다.
마지막으로 호스트가 상태 비저장 및 상태 저장 자동 구성을 모두 사용할 수도 있습니다. 이 경우 라우터 알림에 포함된 주소와 DHCPv6 서버에서 검색된 주소가 함께 사용됩니다.

자동 구성된 주소 상태
DAD(중복된 주소 검색)를 통해 주소의 고유성을 검사하는 중이면 자동 구성된 주소가 미정 상태로 나타납니다. DAD의 실행 방식에 대한 자세한 내용은 "RFC 2462 IPv6 자동 구성 프로세스" 추가 기사를 참조하십시오. 고유한 것으로 확인된 유효한 상태의 주소는 유니캐스트 트래픽을 보내고 받는 데 사용될 수 있습니다. 유효한 상태에는 기본 설정 상태와 사용되지 않음 상태가 있습니다. 기본 설정 상태의 주소는 제한 없는 통신에 사용할 수 있고, 사용되지 않음 상태의 주소는 새 통신에는 사용할 수 없지만 기존 통신에 사용 중이라면 계속 사용할 수 있습니다.
RFC 2462 IPv6 자동 구성 프로세스
다음 단계에서는 RFC 2462에 정의된 IPv6 호스트의 자동 구성 프로세스에 대해 설명합니다.
  • EUI(Extended Unique Identifier)-64 인터페이스 ID를 사용하여 미정 링크-로컬 주소를 얻습니다.
  • 대상 주소가 미정 링크-로컬 주소로 설정된 인접 라우터 요청 메시지를 보내서 미정 링크-로컬 주소에 대해 DAD를 수행합니다.
  • 미정 링크-로컬 주소가 중복된 주소이면 인접 라우터 요청 메시지에 대한 응답으로 전송된 인접 라우터 알림 메시지가 수신됩니다. 주소 자동 구성을 중지합니다. 이 경우 호스트에서 수동 구성을 수행해야 합니다.
  • 미정 링크-로컬 주소가 고유한 주소이면 인접 라우터 요청 메시지에 대한 응답으로 전송된 인접 라우터 알림 메시지가 수신되지 않습니다. 인터페이스에서 주소의 상태를 기본 설정으로 변경합니다.
  • 라우터 요청 메시지를 보냅니다.
  • 라우터 알림 메시지가 수신되지 않으면 DHCPv6을 사용하여 주소와 기타 구성 매개 변수를 가져옵니다.
  • 라우터 알림 메시지가 수신되면 포함된 접두사에 대해 미정 주소를 구성하고 각 미정 주소를 대상으로 중복된 주소 검색을 수행합니다. 주소가 고유하면 인터페이스에서 주소의 상태를 기본 설정으로 변경합니다.
  • 라우터 알림 메시지의 M 플래그가 1로 설정되어 있으면 DHCPv6을 사용하여 추가 상태 저장 주소를 가져옵니다.
  • 라우터 알림 메시지의 M 플래그가 0으로 설정되어 있고 O 플래그가 1로 설정되어 있으면 DHCPv6을 사용하여 추가 구성 매개 변수를 가져옵니다.

알림 라우터 또는 DHCPv6 서버에서는 주소 접두사의 유효 수명과 기본 설정 수명을 지정합니다. 주소의 기본 설정 수명이 초과되면 해당 주소가 사용되지 않음 상태로 바뀝니다. 자동 구성된 주소의 기본 설정 수명은 라우터 알림을 수신하거나 DHCPv6 주소 구성을 갱신하는 방법으로 새로 고쳐집니다. 그림 1에서는 자동 구성된 주소의 상태와 기본 설정 수명 및 유효 수명과의 관계를 보여 줍니다.
그림 1 자동 구성된 주소의 상태
그림 1 자동 구성된 주소의 상태
링크-로컬 주소의 자동 구성을 제외하면 주소 자동 구성은 IPv6 호스트에 대해서만 지정됩니다. 따라서 IPv6 라우터는 수동 구성 등의 다른 방법으로 주소와 구성 매개 변수를 가져와야 합니다.
RFC 2462에 정의된 호스트의 IPv6 주소 자동 구성 프로세스는 "RFC 2462 IPv6 자동 구성 프로세스" 추가 기사에 자세히 설명되어 있습니다.

Windows Vista의 IPv6 자동 구성 동작
Windows Vista® 또는 Windows Server® 2008(이전 코드 이름 "Longhorn")을 실행하는 컴퓨터에서는 공용 주소 및 링크-로컬 주소를 비롯한 일시적이지 않은 자동 구성 IPv6 주소에 대해 기본적으로 EUI-64 기반 인터페이스 ID 대신 임의 인터페이스 ID를 생성합니다. 공용 IPv6 주소는 DNS에 등록된 전역 주소이며 들어오는 연결을 위해 웹 서버와 같은 서버 응용 프로그램에 주로 사용됩니다. 다음 명령을 사용하면 이 기본 동작을 해제할 수 있습니다.
netsh interface ipv6 set global randomizeidentifiers=disabled
이 기본 동작이 해제되면 IPv6에서 EUI-64 기반 인터페이스 ID가 사용됩니다.
임의로 파생된 인터페이스 ID를 사용하면 링크-로컬 주소가 중복될 가능성이 매우 낮습니다. 따라서 Windows Vista나 Windows Server 2008을 실행하는 컴퓨터는 파생된 링크-로컬 주소를 사용하여 라우터 요청 메시지를 보내기 전에 DAD가 완료되기를 기다리지 않습니다. 이것을 낙관적 DAD라고 하며, 인터페이스 초기화 프로세스 중에 라우터 검색과 DAD가 병렬로 실행되므로 시간이 단축됩니다.
Windows Vista나 Windows Server 2008을 실행하는 컴퓨터는 라우터 알림이 수신되지 않으면 DHCPv6을 사용한 상태 저장 주소 자동 구성을 시도하지 않습니다.
Windows Vista IPv6 자동 구성 프로세스
다음 단계에서는 Windows Vista를 실행하는 IPv6 호스트의 자동 구성 프로세스에 대해 설명합니다.
  • 임의로 파생된 인터페이스 ID(기본 설정)를 사용하여 LAN 인터페이스의 미정 링크-로컬 주소를 얻습니다.
  • 대상 주소 필드가 미정 링크-로컬 주소로 설정된 인접 라우터 요청 메시지를 보내는 방법으로 LAN 인터페이스의 파생된 링크-로컬 주소에 대해 DAD를 수행합니다.
  • 미정 링크-로컬 주소에서 라우터 요청 메시지를 보내는 방법으로 LAN 인터페이스에 대해 라우터 검색을 수행합니다.
  • 2단계에서 전송된 인접 라우터 요청 메시지에 대한 응답으로 전송된 인접 라우터 알림 메시지가 수신되면 링크-로컬 주소를 중복된 것으로 표시합니다.
  • 인접 라우터 요청 메시지에 대한 응답으로 인접 라우터 알림 메시지가 수신되지 않으면 LAN 인터페이스의 링크-로컬 주소 상태를 기본 설정으로 변경합니다.
  • 라우터 알림이 수신되지 않으면 LAN 인터페이스에서 IPv6 주소 자동 구성을 중지합니다. 13단계로 이동합니다.
  • 라우터 알림이 수신되면 1단계에서 파생된 임의 인터페이스 ID를 기준으로 메시지의 전역 또는 고유 로컬 주소 접두사에 해당하는 미정 공용 주소를 만든 다음, DAD를 수행합니다.
  • 임의로 파생된 새 인터페이스 ID를 사용하여 메시지의 전역 또는 고유 로컬 주소 접두사에 해당하는 미정 임시 주소를 만든 다음, DAD를 수행합니다.
  • 각 주소에 대해 인접 라우터 요청 메시지에 대한 응답으로 인접 라우터 알림 메시지가 수신되지 않으면 LAN 인터페이스의 주소 상태를 기본 설정으로 변경합니다.
  • 라우터 알림에 M 플래그와 O 플래그가 모두 0으로 설정되어 있으면 LAN 인터페이스에서 IPv6 자동 구성을 중지합니다. 13단계로 이동합니다.
  • 라우터 알림의 M 플래그가 1로 설정되어 있으면 DHCPv6을 사용하여 상태 저장 IPv6 주소와 추가 구성 설정을 모두 가져옵니다.
  • 라우터 알림의 M 플래그가 0으로 설정되어 있고 O 플래그가 1로 설정되어 있으면 DHCPv6을 사용하여 추가 구성 설정을 가져옵니다.
  • LAN 인터페이스의 IPv4 주소를 기반으로 링크-로컬 ISATAP 주소를 얻어서 ISATAP 터널링 인터페이스에 할당합니다.
  • 호스트 이름 "ISATAP"를 IPv4 주소로 확인합니다.
  • 호스트 이름 "ISATAP"를 확인할 수 없으면 IPv6 구성을 중지합니다.
  • 호스트 이름 "ISATAP"가 IPv4 주소로 확인되면 ISATAP 라우터에 IPv4로 캡슐화된 라우터 요청을 보냅니다.
  • ISATAP 라우터로부터 라우터 알림이 수신되면 알림의 전역 또는 고유 로컬 주소 접두사에 해당하는 추가 ISATAP 주소를 만들어 ISATAP 터널링 인터페이스에 할당합니다.

Windows Vista의 자동 구성된 주소
앞서 설명한 것과 같이 Windows Vista와 Windows Server 2008의 IPv6 프로토콜은 모든 LAN 인터페이스에 대해 임의로 파생된 인터페이스 ID를 사용하여 링크-로컬 주소를 자동으로 구성합니다.
수신된 라우터 알림에 전역 또는 고유 로컬 접두사가 포함되어 있으면 IPv6이 임의로 파생된 동일한 인터페이스 ID를 사용하여 전역 또는 고유 로컬 주소를 만들고 라우터 알림을 수신한 LAN 인터페이스에 이 주소를 할당합니다. 이와 같은 주소를 공용 주소라고 합니다.
기본적으로 Windows Vista의 IPv6은 임의로 파생된 다른 인터페이스 ID를 사용하여 임시 전역 또는 고유 로컬 주소를 구성하고 라우터 알림을 수신한 LAN 인터페이스에 이 주소를 할당합니다. RFC 3041에 정의되어 있는 임시 주소는 클라이언트에서 시작된 통신에 일정 수준의 익명성을 제공하는 데 사용됩니다. 반면 Windows Server 2008의 IPv6에서는 기본적으로 임시 주소가 생성되지 않습니다. 하지만 다음 명령을 사용하면 임시 주소를 사용하도록 설정할 수 있습니다.
netsh interface ipv6 set privacy-enabled
수신된 라우터 알림 메시지에 M 플래그가 1로 설정되어 있으면 IPv6은 DHCPv6을 사용하여 LAN 인터페이스의 추가 전역 또는 고유 로컬 주소를 구성합니다.
IPv6은 호스트의 각 LAN 인터페이스에 대해 ISATAP(Intra-site Automatic Tunnel Addressing Protocol) 터널링 인터페이스도 만듭니다. RFC 4214에는 ISATAP IPv6 전환 기술이 설명되어 있습니다. ISATAP를 사용하면 IPv6 호스트가 IPv4 헤더로 IPv6 패킷을 캡슐화하여 IPv4 전용 인트라넷에서 통신할 수 있습니다. ISATAP에 대한 자세한 내용은 "IPv6 전환 기술"을 참조하십시오.
IPv6은 각 ISATAP 터널링 인터페이스별로 해당 LAN 인터페이스에 할당된 IPv4 주소에 사용할 링크-로컬 ISATAP 주소를 구성합니다. 예를 들어 IPv4 주소 192.168.91.211이 할당된 LAN 인터페이스에 해당하는 ISATAP 터널링 인터페이스의 경우 IPv6은 FE80::0:5EFE:192.168.91.211이라는 링크-로컬 ISATAP 주소를 할당합니다.
ISATAP 호스트는 ISATAP 라우터 검색도 수행합니다. IPv6이 ISATAP 라우터에서 라우터 알림을 수신하려면 기본적으로 호스트 이름 "ISATAP"를 IPv4 주소로 확인할 수 있어야 합니다. 이러한 주소 확인은 DNS와 같은 Windows 기반 호스트 이름 확인 방식을 통해 이루어집니다. 이름이 확인되면 호스트가 IPv4로 캡슐화된 라우터 요청을 ISATAP 라우터에 보냅니다. 그러면 ISATAP 라우터는 IPv4로 캡슐화된 라우터 알림을 호스트에 보냅니다. IPv6은 수신된 라우터 알림의 내용에 따라 ISATAP 터널링 인터페이스에 대해 전역 또는 고유 로컬 ISATAP 주소도 구성합니다.
Windows Vista에서는 6to4 및 Teredo IPv6 전환 기술도 지원합니다. 그러나 이 칼럼에서는 설명을 간단히 하기 위해 Windows Vista 기반 IPv6 호스트의 6to4 및 Teredo 터널링 인터페이스 자동 구성에 대해서는 다루지 않겠습니다.
"Windows Vista IPv6 자동 구성 프로세스" 추가 기사에서는 LAN 또는 ISATAP 터널링 인터페이스에서 전역 또는 고유 로컬 주소 접두사를 사용하여 구성된 단일 LAN 인터페이스가 있는 Windows Vista 기반 IPv6 호스트의 주소 자동 구성 프로세스에 대해 설명합니다.
예를 들어 Windows Vista를 실행하는 호스트에 단일 LAN 인터페이스가 있다고 가정해 봅니다. 이 호스트는 M 플래그와 O 플래그가 모두 0으로 설정되어 있고 접두사 2001:DB8:D005:F282::/64 및 FD4A:3A9:27A1:F282::/64가 포함된 자체 LAN 인터페이스에서 라우터 알림을 수신합니다. ISATAP 라우터로부터의 라우터 알림 메시지는 수신하지 않습니다. 그림 2에서는 이 예제 호스트에 대해 명령을 실행한 결과로 출력된
Figure 2 netsh interface ipv6 show address의 출력 (Close Figure 2)
Interface 1: Loopback Pseudo-Interface 1

Addr Type DAD State Valid Life Pref. Life Address
--------- ----------- ---------- ---------- ------------------------
Other   Preferred  infinite infinite ::1

Interface 8: Local Area Connection

Addr Type DAD State Valid Life Pref. Life Address
--------- ----------- ---------- ---------- ------------------------
Temporary Preferred 6d19h37m21s 6d19h37m21s 2001:db8:d005:f282:ed46:5dd4:5439:2e1c
Public  Preferred  infinite infinite 2001:db8:d005:f282:3521:12fa:2c44:87d1
Temporary Preferred 6d19h37m21s 6d19h37m21s fd4a:3a9:27a1:f282:ed46:5dd4:5439:2e1c
Public   Preferred  infinite infinite fd4a:3a9:27a1:f282:3521:12fa:2c44:87d1
Other   Preferred  infinite infinite fe80::3521:12fa:2c44:87d1%8

Interface 17: Local Area Connection* 9

Addr Type DAD State Valid Life Pref. Life Address
--------- ----------- ---------- ---------- ------------------------
Other   Preferred  infinite infinite fe80::5efe:10.47.181.92%17

netsh interface ipv6 show address
예를 보여 줍니다. 이 그림에서 로컬 영역 연결이라는 LAN 인터페이스에 해당하는 ISATAP 터널링 인터페이스의 이름은 Local Area Connection* 9로 지정되어 있습니다.
Windows Server 2008과 Windows Vista의 IPv6 프로토콜은 자동 구성된 주소뿐만 아니라 다음 명령을 사용한 수동 정적 IPv6 주소 구성도 지원합니다.
netsh interface ipv6 add address
또는 네트워크 연결 폴더에 있는 연결의 속성에서 TCP/IPv6(인터넷 프로토콜 버전 6) 구성 요소를 통해 수동으로 구성할 수도 있습니다.
이번 달 칼럼은 IPv6 주소 지정 및 프로토콜 작업에 대한 기본적인 지식을 갖춘 독자를 대상으로 작성했습니다. 이 항목에 대해 자세한 정보가 필요하면 "IPv6 소개" 백서(microsoft.com/technet/ network/ipv6/introipv6.mspx)를 참조하시기 바랍니다.

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


 Windows PowerShell: 필터링의 유용성
Windows PowerShell
필터링의 유용성
Don Jones

지난 달 칼럼에서는 cmdlet 간에 데이터 집합(엄밀히 말하면 개체의 스트림)을 전달하는 방식으로 필요에 따라 집합을 더욱 정밀하게 다듬을 수 있는 Windows PowerShell 파이프라인의 강력한 기능과 유연성에 대해 알아보았습니다. 그때 cmdlet뿐만 아니라 개발자가 직접 작성한 스크립트에도
파이프라인의 이점을 활용할 수 있다는 사실을 언급한 바 있습니다. 이번 달 칼럼에서는 이 주제에 대해 자세히 다루겠습니다.
필자는 일반적으로 WMI(Windows® Management Instrumentation)를 통해 여러 원격 컴퓨터에 대해 작동하는 스크립트를 작성하는 데 Windows PowerShell™을 가장 많이 사용합니다. 원격 컴퓨터를 다루는 모든 작업이 그렇듯이, 스크립트를 실행할 때 이러한 컴퓨터가 정상적으로 작동하지 않을 가능성은 늘 존재합니다. 따라서 이러한 문제를 처리할 수 있는 스크립트를 작성해야 합니다.
물론 다양한 방법으로 스크립트가 WMI 연결 시간 제한을 처리하도록 할 수 있지만, 제한 시간(기본 30초) 자체가 너무 길기 때문에 개인적으로 이러한 접근 방식이 마음에 들지 않았습니다. 수많은 시간 제한이 발생하길 기다려야 한다면 스크립트 실행 속도가 너무 느려지니까요. 그래서 필자는 컴퓨터에 연결하기 전에 해당 컴퓨터가 실제로 온라인 상태인지를 신속히 확인하도록 스크립트를 작성합니다.

Windows PowerShell 패러다임
VBScript와 같은 다른 스크립팅 언어에서는 대개 한 번에 하나의 컴퓨터에 대해서만 작업을 수행하게 됩니다. 즉, 텍스트 파일에 저장된 이름 목록 등에서 컴퓨터 이름을 검색하고 ping 테스트를 통해 해당 시스템을 사용할 수 있는지 확인하게 됩니다. 그리고 시스템을 사용할 수 있으면 WMI를 연결하고 필요한 작업을 수행합니다. 이는 매우 일반적인 스크립팅 스타일의 방법입니다. 사실 필자라면 이러한 방법 대신 모든 코드를 루프로 작성한 후 연결할 컴퓨터마다 한 번씩 루프를 반복할 겁니다.
반면 Windows PowerShell은 개체를 기반으로 하고 개체의 그룹 또는 컬렉션을 대상으로 직접 작업을 수행할 수 있다는 점에서 일괄 작업에 훨씬 적합합니다. Windows PowerShell의 패러다임은 단일 개체나 데이터 조각이 아니라, 전체 그룹을 가지고 작업하면서 처음 설정했던 목표를 달성할 때까지 그룹을 조금씩 조정해 가는 것입니다. 예를 들어 목록에서 컴퓨터 이름을 한 번에 하나만 검색하는 게 아니라 전체 이름 컬렉션을 한꺼번에 읽는 것입니다. 또한 루프에 포함된 각 컴퓨터에 대해 ping 테스트를 수행하는 대신 이름 컬렉션을 받아 ping 테스트를 수행한 후 연결 가능한 컴퓨터 이름만 출력하는 단일 루틴을 작성합니다. 그 다음 단계는 이렇게 얻은 이름, 다시 말해 ping 테스트로 연결할 수 있는 이름에 대해 WMI 연결을 만드는 것입니다.
Windows PowerShell에서도 바로 이 접근 방식을 사용하여 수많은 작업을 수행합니다. 예를 들어 실행 중인 서비스 목록을 얻으려면 다음과 같은 코드를 사용하면 됩니다.
Get-Service | Where-Object { $_.Status –eq "Running" }
그림 1은 필자의 컴퓨터에 출력된 결과입니다. 서비스를 한 번에 하나씩 확인하지 않고, Get-Service를 사용하여 모든 서비스를 검색한 다음 이를 Where-Object에 파이프로 연결하여 실행 중이 아닌 서비스를 필터링으로 걸러냈습니다. 필자가 스크립트에서 구현하려는 것도 이와 유사합니다. 말하자면, 컴퓨터 이름 목록을 가져와 ping 테스트를 통과하지 못한 컴퓨터를 필터링한 다음 ping 테스트를 통과한 컴퓨터를 다음 단계로 전달하는 것입니다.
그림 1 ping 테스트를 통과한 컴퓨터 목록 얻기
그림 1 ping 테스트를 통과한 컴퓨터 목록 얻기

필터링 함수
이러한 기능을 수행하는 cmdlet를 직접 작성할 수도 있지만 그 방법은 별로 좋아하지 않습니다. cmdlet를 작성하려면 Visual Basic®이나 C#뿐만 아니라 Microsoft® .NET Framework 개발에 대한 전문 지식이 많이 필요합니다. 그리고 무엇보다도 작업에 더 많은 시간을 할애해야 한다는 점이 문제입니다. 다행히 Windows PowerShell을 사용하면 파이프라인 내에서 완벽하게 작동하는 필터라는 특수 함수를 작성할 수 있습니다. 필터링 함수의 기본 형식은 다음과 같습니다.
function <name> {
  BEGIN {
    #<code>
  }
  PROCESS {
    #<code>
  }
  END {
    #<code>
  }
}
위에서 볼 수 있듯이 이 함수에는 BEGIN, PROCESS, END라는 세 가지 독립적인 스크립트 블록이 있습니다. 필터링 함수(파이프라인 내에서 개체를 필터링하도록 작성된 함수)에는 원하는 작업에 따라 이 세 가지 스크립트 블록을 자유롭게 조합해서 사용할 수 있습니다. 각 블록은 다음과 같이 작동합니다.
  • BEGIN 블록은 함수를 처음 호출할 때 한 번 실행되며, 필요한 경우 설정 작업을 수행하는 데 사용할 수 있습니다.
  • PROCESS 블록은 함수로 전달되는 각 파이프라인 개체마다 한 번씩 실행됩니다. $_ 변수는 현재 파이프라인 입력 개체를 나타냅니다. 필터링 함수에서 PROCESS는 필수 블록입니다.
  • END 블록은 모든 파이프라인 개체가 처리된 후에 한 번 실행되며, 필요한 경우 모든 종류의 종료 작업에 사용할 수 있습니다.
필자의 예제 스크립트에서는 이름 컬렉션을 입력 개체로 받아 각 이름에 대해 ping 테스트를 실행하는 필터링 함수를 만들려고 합니다. 테스트를 통과하는 모든 이름이 파이프라인에 결과로 출력되고, 통과하지 못하는 시스템은 버려집니다. ping 기능은 특별한 설정이나 종결 과정이 필요 없으므로 PROCESS 스크립트 블록만 사용하면 됩니다. 그림 2의 코드에는 전체 스크립트가 나와 있습니다.
Figure 2 Ping-Address 및 Restart-Computer (Close Figure 2)
1  function Ping-Address {
2    PROCESS {
3      $ping = $false
4      $results = Get-WmiObject -query `
5      "SELECT * FROM Win32_PingStatus WHERE Address = '$_'"
6      foreach ($result in $results) {
7        if ($results.StatusCode -eq 0) {
8          $ping = $true
9        }
10      }
11      if ($ping -eq $true) {
12        Write-Output $_
13      }
14    }
15  }
16
17  function Restart-Computer {
18    PROCESS {
19      $computer = Get-WmiObject Win32_OperatingSystem -computer $_
20      $computer.Reboot()
21    }
22  }
23
24  Get-Content c:\computers.txt | Ping-Address | Restart-Computer
이 예에서 필자는 Ping-Address와 Restart-Computer라는 두 가지 함수를 정의했습니다. Windows PowerShell에서 함수를 호출하려면 그 전에 먼저 정의해야 합니다. 따라서 예제 스크립트에서 처음 실행되는 줄은 Get-Content cmdlet를 사용하여 파일에서 컴퓨터 이름 목록(한 줄에 하나의 컴퓨터 이름)을 가져오는 24번째 줄입니다. 이 목록, 정확히 말해 String 개체 컬렉션은 ping이 불가능한 컴퓨터를 모두 필터링하는 Ping-Address 함수에 파이프로 연결됩니다. 그 결과가 Restart-Computer 함수에 파이프로 연결되며 이 함수는 ping이 가능한 각 컴퓨터를 WMI를 사용하여 원격으로 다시 시작합니다.
Ping-Address 함수는 PROCESS 스크립트 블록을 구현합니다. 다시 말해 이 함수에는 입력 개체 컬렉션이 필요합니다. PROCESS 스크립트 블록은 이러한 입력을 자동으로 처리하므로 입력을 포함하기 위해 입력 인수를 정의할 필요가 없었습니다. 그리고 세 번째 줄에서 $ping 변수를 부울 값 False를 나타내는 기본 제공 Windows PowerShell 변수인 $false로 설정하여 프로세스를 시작했습니다.
다음으로, 로컬 Win32_PingStatus WMI 클래스를 사용하여 지정한 컴퓨터를 ping 테스트합니다. 다섯 번째 줄에서 현재 파이프라인 개체를 나타내는 $_ 변수가 WMI 쿼리 문자열에 포함되어 있는 것을 알 수 있습니다. 문자열이 큰따옴표에 포함되어 있으면 Windows PowerShell은 항상 $_과 같은 변수를 해당 내용으로 대체하므로 문자열 연결을 위한 작업을 직접 수행할 필요가 없습니다. 다섯 번째 줄에 이러한 기능이 사용되었습니다.
여섯 번째 줄은 ping 결과를 확인하는 루프입니다. 성공적으로 반환된 결과(StatusCode가 0인 결과)가 있으면 $ping을 $true로 설정하여 테스트에 성공했음을 나타냅니다. 11번째 줄에서 $ping이 $true로 설정되어 있는지 확인합니다. $true로 설정되어 있으면 원래 입력 개체를 기본 출력 스트림으로 출력합니다. Windows PowerShell은 기본 출력 스트림을 자동으로 관리합니다. 즉, 해당 함수가 파이프라인 끝에 있으면 출력 스트림이 텍스트 표현으로 바뀝니다. 또한 파이프라인에 다른 명령이 더 있으면 출력 스트림의 개체(예제의 경우 컴퓨터 이름이 들어 있는 문자열 개체)가 다음 파이프라인 명령으로 전달됩니다.
Restart-Computer 함수는 보다 간단하지만, 역시 PROCESS 블록을 사용하므로 파이프라인에 쉽게 참여할 수 있습니다. 19번째 줄에서 이 함수는 명명된 컴퓨터에 연결하고 해당 컴퓨터의 Win32_OperatingSystem WMI 클래스를 검색합니다. 20번째 줄에서는 클래스의 Reboot 메서드를 실행하여 원격 컴퓨터를 다시 시작합니다.
앞서 언급했지만 코드가 실제로 실행되는 곳은 24번째 줄입니다. 물론 이 스크립트를 실행할 때는 매우 신중해야 합니다. 왜냐하면 이 스크립트는 c:\computers.txt에 명명된 모든 컴퓨터를 다시 부팅하도록 설계되어 있어 이 텍스트 파일에 있는 이름을 잘 살피지 않으면 엄청난 결과를 초래할 수 있기 때문입니다.

다음 단계
이 스크립트가 완벽한 것은 아닙니다. 원격 컴퓨터에서 필요한 포트가 방화벽에 의해 차단되는 오류나 WMI 보안 오류와 같이 기본 연결과 관련 없는 WMI 오류의 가능성에 대해서도 인식해야 합니다. 이러한 문제는 트랩 처리기를 구현하면 처리할 수 있습니다. 여기에 대한 자세한 내용은 향후 칼럼에서 다루도록 하겠습니다.
또한 이 스크립트는 원격 컴퓨터를 다시 시작하는 상당히 위험한 작업을 수행합니다. 이처럼 위험성이 있는 작업을 시도하는 스크립트에서는 자주 사용되는 두 가지 Windows PowerShell 매개 변수(–Confirm 및 –WhatIf)를 구현해야 합니다. 자세한 구현 방법은 지면상 설명하기가 곤란하므로 역시 향후 칼럼에서 다루도록 하겠습니다. 지금은 우선 Windows PowerShell 팀 블로그를 확인해 보십시오. 설계자로 일하고 있는 Jeffrey Snover가 이 항목에 대해 다루고 있습니다.
이러한 기능을 모르더라도 필터링 함수의 기능에 대해 쉽게 알 수 있습니다. 앞으로 칼럼을 통해 계속 자세한 기법을 소개하면서, 함수를 사용하여 재사용이 가능한 코드를 모듈화하고 스크립트의 일반적인 기능을 향상시키는 방법을 설명할 예정입니다.

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


 Hey, Scripting Guy!: 소개
Hey, Scripting Guy!
소개
Microsoft Scripting Guys
이 기사의 코드 다운로드: HeyScriptingGuy2007-082007_08.exe (152KB)

얼마 전 이 칼럼을 쓰는 Scripting Guy가 TV로 야구 중계를 시청하고 있었습니다. 경기가 끝난 후 그는 TV를 켜 놓은 채 잡지를 읽기 시작했습니다. 잡지를 다 읽고 무심코 TV를 봤는데 제2차 세계 대전에 관한 영화가 방영되고 있었습니다. 그리고 마침 진짜 같은 이야기가 전개되고 있었습니다. 늦은 밤, 젊은 미군 한 명이 보초를 서고 있는데 인기척을 듣게 된 것이죠.
"거기 누구냐?"고 초병이 소리쳤습니다.
"스미스 중사다"라는 대답이 들려왔습니다.
"스미스 중사? 우리 부대에 스미스 중사는 없다."
"방금 A 중대에서 이곳으로 전근했다."
"아, 그러시다고요? A 중대에서 말이죠? 그렇다면 중사님. 1934 월드 시리즈 우승 팀이 어디입니까?"
"뉴욕 양키즈지."
어처구니가 없군요. "스미스"! (뭐, 다들 예상 했겠지만 이 사람은 바로 체포된 후 영창으로 보내졌습니다.) 선량한 미국 시민이라면, 진짜 미국 시민이라면 누구나 Gas House Gang이라 불리던 전설적인 Dizzy Dean이 활약한 세인트루이스 카디널스가 1934년 월드 시리즈 우승을 차지한 사실을 알고 있습니다. 이 사실을 모른다면 모두 스파이라는 말이죠.
이달의 칼럼을 읽는 독자 중에도 세인트루이스 카디널스가 1934년 월드 시리즈 우승 팀이라는 사실을 모르는 사람이 있다면 이렇게 말해 주고 싶군요. "이제 모든 게 들통났습니다. 정체를 밝히시죠!"라고 말입니다. 지금 당장 순순히 가까운 FBI 지서에 자수할 것을 권하는 바입니다. 뭐, 아니면 전화만 한 통 주시면 FBI에서 친절히 모셔갈 것입니다.
이 칼럼을 집필하는 Scripting Guy는 영화를 계속 보면서 만약 초병이 질문을 더 했더라도 자기는 충분히 대답할 수 있었을 것이라는 생각을 했습니다. 1966 월드 시리즈 우승 팀은? 볼티모어 오리올스. 1960 월드 시리즈 우승 팀은? 피츠버그 파이러츠. 1994 월드 시리즈 우승 팀은? 호! 이 질문은 속임수군요. 1994년에는 월드 시리즈가 열리지 않았습니다.
그러나 요즘 맨 처음 질문에 대답하기가 너무 어렵다는 생각이 듭니다. "너는 누구냐?"라는 질문 말입니다. 1940년대에 비해 이 질문에 대답하기가 너무 어려워진 것 같습니다. Active Directory®만 해도 사용자가 다음과 같이 여러 가지 ID를 사용할 수 있으니까요.
  • 이름(givenName).
  • 성(sn).
  • 표시 이름(displayName).
  • UPN(userPrincipalName).
  • 로그온 이름(samAccountName).
  • 고유 이름(distinguishedName).
이러한 이름은 모두 동일인을 나타내고, 상황에 따라 모두 필요한 이름들입니다. 이것이 바로 문제입니다. 자신의 성과 이름을 모르는 사람은 없겠지만, "고유 이름은 무엇입니까?"라고 물었을 때 "간단합니다. CN=Ken.Myer, OU=Finance, DC=fabrikam, DC=com입니다. 친구들은 다들 CN=Ken.Myer라고 부르죠."라고 대답할 수 있는 사람은 몇 안 될 테니까요.
시스템 관리자 또는 지원 담당자도 이러한 사용자의 이름을 알고 있어야 합니다. 그렇다면 이 정보는 과연 어떻게 얻어야 하는 것일까요? 고유 이름을 실토할 때까지 무섭게 다그치는 것도 한 방법이 될 수 있겠죠. 뭐, 이 방법도 먹히기는 하겠지만 현대의 인사 부서에서 이런 방법을 사용할 수는 없는 노릇입니다. 그렇다면 차선책으로 스크립트를 사용할 수 있습니다. 어떤 스크립트를 사용해야 할까요? 먼저 그림 1의 스크립트부터 살펴보겠습니다.
Figure 1 ADSystemInfo를 사용한 사용자 특성 검색 (Close Figure 1)
On Error Resume Next

Set objSysInfo = CreateObject("ADSystemInfo")
strUser = objSysInfo.UserName

Set objUser = GetObject("LDAP://" & strUser)
WScript.Echo "First Name: " & objUser.givenName
WScript.Echo "Last Name: " & objUser.sn
WScript.Echo "Display Name: " & objUser.displayName
WScript.Echo "User Principal Name: " & objUser.userPrincipalName
WScript.Echo "SAM Account Name: " & objUser.sAMAccountName
WScript.Echo "Distinguished Name: " & objUser.distinguishedName
스미스 중사라고 주장한 사람이 VBScript만 공부했어도 잡히지는 않았겠죠? 이 스크립트는 사람들이 잘 모르지만 매우 유용한 ADSystemInfo라는 ADSI 개체를 활용합니다. ADSystemInfo는 현재 로컬 컴퓨터에 로그온한 사용자는 물론, 로컬 컴퓨터 자체와 컴퓨터가 속한 도메인에 대한 정보를 모두 반환하는 유용한 개체입니다. 그 예로 그림 2를 살펴보시기 바랍니다.
Figure 2 모든 종류의 도메인 정보 표시 (Close Figure 2)
On Error Resume Next

Set objSysInfo = CreateObject("ADSystemInfo")

Wscript.Echo "User name: " & objSysInfo.UserName
Wscript.Echo "Computer name: " & objSysInfo.ComputerName
Wscript.Echo "Site name: " & objSysInfo.SiteName
Wscript.Echo "Domain short name: " & objSysInfo.DomainShortName
Wscript.Echo "Domain DNS name: " & objSysInfo.DomainDNSName
Wscript.Echo "Forest DNS name: " & objSysInfo.ForestDNSName
Wscript.Echo "PDC role owner: " & objSysInfo.PDCRoleOwner
Wscript.Echo "Schema role owner: " & objSysInfo.SchemaRoleOwner
Wscript.Echo "Domain is in native mode: " & objSysInfo.IsNativeMode
그러나 지금은 UserName 속성에 대해서만 알면 됩니다. UserName은 무엇이 그렇게 특별할까요? 뭐, 따지자면 단지 distinguishedName 속성에 해당할 뿐입니다. 그렇다면 distinguishedName은 무엇이 그렇게 특별할까요? distinguishedName도 UNC 파일 경로와 유사할 뿐입니다. 즉, UNC 경로를 사용하여 네트워크에서 파일을 고유하게 식별할 수 있는 것과 마찬가지로 distinguishedName(예: CN=Ken.Myer, OU=Finance, DC=fabrikam, DC=com)을 사용하면 Active Directory에서 사용자 계정을 고유하게 식별할 수 있습니다. 그리고 결과적으로 해당 사용자 계정에 사용자를 바인딩할 수 있는 겁니다. 이러한 연결이 만들어지면 사용자가 누구인지에 관한 것부터, 사용자에 대한 모든 정보를 검색할 수 있게 됩니다.
앞서 살펴본 첫 번째 스크립트가 바로 이러한 역할을 합니다. 먼저 ADSystemInfo 개체의 인스턴스를 만든 후에 UserName 속성의 값을 strUser라는 변수에 할당합니다.
Set objSysInfo = CreateObject("ADSystemInfo")
strUser = objSysInfo.UserName
여기서는 별다르게 작업할 내용이 없습니다. 다시 말해 사용자 이름, 사용자 도메인 또는 사용자 계정이 있는 OU를 지정할 필요가 없습니다. 이 모든 작업을 ADSystemInfo가 대신 다 해주니까요. 사용자의 distinguishedName만 있으면 다음 코드 줄을 사용하여 해당 사용자의 사용자 계정에 바인딩할 수 있습니다.
Set objUser = GetObject("LDAP://" & strUser)
그리고 앞서 언급했듯이 연결만 만들면 해당 계정의 모든 Active Directory 특성 값을 출력할 수 있습니다. 샘플 스크립트에서는 사용자의 이름 속성 중 일부만 출력했지만 원한다면 전화 번호, 사무실 위치, 전자 메일 주소 등도 간단하게 검색할 수 있습니다.
멋지지 않습니까? 이 스크립트를 모든 사용자에게 배포하기만 하면 사용자가 "자신의 정보"를 궁금해하는 일은 없을 것입니다. 또한 자신의 고유 정보가 필요한 경우에도 쉽고 빠르게 알아낼 수 있습니다. 하지만 이와 관련한 질문, "너는 누구냐?"의 경우에는 어떨까요. 로컬 컴퓨터에 로그온한 사용자는 이렇게 식별할 수 있다 하더라도, 원격 컴퓨터에 로그온한 사용자가 누구인지는 어떻게 확인해야 할까요? 이미 눈치챘겠지만 이는 훨씬 어려운 문제입니다.
그리고 안타깝게도 원격 컴퓨터를 대상으로 ADSystemInfo 스크립트를 사용할 수는 없습니다. 그 이유는 바로 ADSystemInfo 개체가 로컬로만 만들어지기 때문입니다. 따라서 이 과제는 다음 세 가지 방법으로만 해결할 수 있습니다.
  • 바로 액세스 가능한 위치에 로그온한 사용자의 이름을 기록하는 로그온 스크립트를 작성합니다.
  • Win32_ComputerSystem WMI 클래스와 UserName 속성을 사용합니다.
  • 다른 방법을 찾아봅니다.
가장 합리적으로 보이는 첫 번째 방법을 사용해 보도록 하겠습니다. 이미 알고 있겠지만 ADSystemInfo 개체는 사용자의 고유 이름뿐만 아니라 컴퓨터의 고유 이름(ComputerName 속성)도 반환할 수 있습니다. 그림 3의 샘플 스크립트를 살펴보십시오.
Figure 3 로그온 스크립트 (Close Figure 3)
On Error Resume Next

Set objSysInfo = CreateObject("ADSystemInfo")

strUser = objSysInfo.UserName
strComputer = objSysInfo.ComputerName

Set objUser = GetObject("LDAP://" & _
    strUser)
strUserName = objUser.displayName

Set objComputer = GetObject("LDAP://" & _
    strComputer)
objComputer.Description = strUserName
objComputer.SetInfo
이 스크립트는 어떤 역할을 하는 것일까요? 우선 UserName 속성과 ComputerName 속성의 값을 수집하여 한 쌍의 변수(strUser 및 strComputer)에 저장합니다. 그리고 앞의 예제에서 설명한 것과 마찬가지로 Active Directory의 사용자 계정을 바인딩하고, displayName 특성의 값을 검색하여 strUserName라는 변수에 저장합니다. 간단하지 않습니까?
그러면 다음 코드 줄을 사용하여 Active Directory 컴퓨터 계정에 연결할 수 있습니다.
Set objComputer = GetObject("LDAP://" & _
    strComputer)
이 연결을 만든 후에는 사용자의 displayName 속성을 컴퓨터의 Description 속성에 할당하고 SetInfo 메서드를 호출하여 Active Directory에 변경 내용을 씁니다.
objComputer.Description = strUserName
objComputer.SetInfo
왜 이렇게 할까요? 간단합니다. Ken Myer라는 사용자가 atl-ws-01이라는 컴퓨터에 로그온한다고 가정해 봅니다. atl-ws-01의 Description 속성 값은 어떻게 될까요? 맞습니다. 바로 컴퓨터에 로그온한 사람의 이름인 Ken Myer가 됩니다. 따라서 atl-ws-01에 누가 로그온했는지 알아보려면 Description 속성만 확인하면 됩니다.
일반적으로는 이 시나리오가 문제 없이 적용되고, 사용자가 로그오프할 때마다 Description 속성을 지우는 로그오프 스크립트가 있으면 더할 나위 없습니다. 그러나 완벽한 해결 방법이 되지는 않습니다. 왜 그럴까요? 그것은, 로그온 스크립트가 실행되지 않는 경우가 있기 때문입니다. 단적인 예로 사용자가 RAS를 사용하여 로그온하면 로그온 스크립트는 실행되지 않습니다. 마찬가지로 사용자가 네트워크 연결을 끊고, 캐시된 자격 증명을 사용하여 로그온한 후 컴퓨터를 다시 네트워크에 연결해도 이 스크립트는 실행되지 않습니다. 사용자가 로그오프하지 않고 그냥 컴퓨터를 끈 경우도 한번 생각해 보십시오. 이 경우에는 해당 사용자에 대해 로그오프 스크립트가 실행되지 않습니다. 자연히 컴퓨터가 실행되지 않더라도 Ken Myer가 아직 atl-ws-01에 로그온한 상태로 나타납니다. 한마디로 유용한 방법이긴 하지만 완벽한 해결책이 될 수 없다는 겁니다.
자, 그렇다면 Win32_ComputerSystem 클래스를 사용하는 두 번째 방법은 어떨까요? 이 방법도 대부분의 경우 문제가 없지만, Win32_ComputerSystem 클래스가 항상 로그온한 사용자의 이름을 반환하는 것은 아니라는 문제가 있습니다. 특히 관리자 권한이 없는 사용자에 대해서나 Windows® 2000을 실행하는 컴퓨터의 경우에 이러한 문제가 많이 발생합니다. 예를 들어 그림 4의 스크립트를 통해 컴퓨터에 로그온한 사용자를 확인할 수도 있지만 100% 보장되지는 않습니다.
Figure 4 WMI로 로그온한 사용자 확인 (Close Figure 4)
strComputer = "."

Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colItems = objWMIService.ExecQuery("Select * From Win32_ComputerSystem")

For Each objItem in colItems
  Wscript.Echo objItem.UserName
Next
이 예제의 경우 UserName 속성이 domain\username의 형식으로 다시 보고됩니다. 즉, FABRIKAM\kenmyer로 나타납니다.
아, 중요한 사실을 잊을 뻔했군요. 이렇게 이름이 다시 반환되더라도 해당 사용자가 컴퓨터에 실제로 로그온한 상태라는 보장은 없습니다. Ken Myer가 atl-ws-01에서 로그오프하면 이 사용자의 이름이 UserName 속성의 값으로 보존되고 다른 사용자가 로그온할 때까지는 바뀌지 않습니다.
역시 이 방법도 안 되겠군요.
잠깐! 그렇다고 해서 잘못된 사용자가 표시되는 것도 아니지 않습니까? 흠, 그러면 이런 방법을 사용해 볼 수도 있겠군요. 누군가 컴퓨터에 로그온하면 Explorer.exe라는 프로세스가 실행됩니다. 대개 Explorer.exe가 실행 중이지 않다면 컴퓨터에 사용자가 로그온하지 않은 경우가 많습니다. 또한 Explorer.exe는 로그온한 사용자의 자격 증명 하에서만 실행되므로 그림 5와 같은 스크립트를 사용하면 컴퓨터에 로그온한 사용자를 거의 항상 정확하게 확인할 수 있습니다.
Figure 5 Explorer.exe의 소유자 확인 (Close Figure 5)
strComputer = "atl-ws-01"

Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colItems = objWMIService.ExecQuery _
  ("Select * from Win32_Process Where Name = 'explorer.exe'")

If colItems.Count = 0 Then
  Wscript.Echo "No one is logged on to the computer."
Else
  For Each objProcess in colItems
    objProcess.GetOwner strUser, strDomain
    Wscript.Echo strDomain & "\" & strUser
  Next
End If
그리고 그림에서 보듯이 이 스크립트에서는 원격 컴퓨터(정확히는 atl-ws-01)의 WMI 서비스에 연결하고 있습니다. 그리고 다음 코드를 사용하여 이름이 Explorer.exe인 Win32_Process 클래스의 인스턴스 컬렉션을 모두 검색합니다.
Set colItems = objWMIService.ExecQuery _
  ("Select * from Win32_Process Where " & _
  "Name = 'explorer.exe'")
다음으로 어떻게 해야 할까요? 조금 전에 설명했듯이 Explorer.exe가 실행되고 있지 않다면 대개 컴퓨터에 사용자가 로그온하지 않은 것입니다. 그렇다면 Explorer.exe의 실행 여부는 어떻게 확인할까요? 간단한 방법으로는 컬렉션의 Count 속성 값을 확인하는 방법이 있습니다. Count 속성이 0이면 컬렉션이 비어 있다는 뜻이고, 이것은 곧 atl-ws-01에서 실행 중인 Explorer.exe 인스턴스가 없음을 의미합니다. 이 경우 다음과 같이 컴퓨터에 로그온한 사용자가 없음을 알리는 메시지를 출력하면 됩니다.
Wscript.Echo "No one is logged on " & _
"to the computer."
반면 Count가 0이 아니라면 프로세스의 컬렉션에 대해 반복 실행되는 For Each 루프를 설정하여 이름이 Explorer.exe인 프로세스를 찾습니다(예제에서는 컬렉션에 항목이 하나밖에 없는 것으로 가정). 그리고 Explorer.exe의 각 인스턴스에 대해 GetOwner 메서드를 호출하여 Explorer.exe가 어느 사용자의 계정으로 실행되고 있는지 확인합니다.
objProcess.GetOwner strUser, strDomain
GetOwner에는 strUser와 strDomain이라는 출력 매개 변수가 한 쌍 전달됩니다. 출력 매개 변수는 우리가 지정하여 메서드에 제공하는 변수로, 메서드에서 이러한 출력 매개 변수에 값을 할당하게 됩니다. 예제의 경우 strUser에 로그온한 사용자의 로그온 이름(kenmyer)이, strDomain에 로그온한 사용자의 도메인 이름(FABRIKAM)이 각각 할당됩니다. 이제 다음과 같이 이 두 출력 매개 변수의 값을 출력하기만 하면 됩니다.
Wscript.Echo strDomain & "\" & strUser
이 방법도 상당히 괜찮긴 하지만 더 효과적인 방법이 있습니다. GetOwner 메서드를 사용하면 컴퓨터에 로그온한 사용자의 로그온 이름(samAccountName)이 반환됩니다. 뭐, 이것이 문제가 되지는 않지만 앞에서 설명한 바와 같이 사용자에게는 samAccountName 외에도 다양한 이름이 할당됩니다. 따라서 "너는 누구냐?"라는 질문에 확실히 대답하려면 사용자의 displayName과 같은 다른 이름도 확인하는 것이 좋습니다. 하지만 GetOwner로 다른 이름을 확인할 수는 없습니다.
그러나 samAccountName을 Active Directory 검색 스크립트에 삽입하고 해당 로그온 이름을 찾아 사용자 계정에 바인딩할 수 있습니다. samAccountName은 도메인 내에서 고유해야 하므로 이 작업은 쉽게 실행할 수 있습니다. 또한 displayName을 비롯한 모든 Active Directory 속성은 일단 사용자 계정에 바인딩하기만 하면 값을 출력할 수 있습니다.
그림 6의 스크립트를 자세히 설명하기에는 지면이 부족하기 때문에, Active Directory 검색에 대한 자세한 내용은 "내 프린터는 어디에?"라는 기사를 참조하시기 바랍니다. 여기서는 이 스크립트가 로그온한 사용자의 로그온 이름을 확인하고, Active Directory에서 로그온 이름에 해당하는 사용자(samAccountName)를 검색하여 해당 사용자 계정에 바인딩하고, 사용자의 displayName을 출력한다는 정도만 설명하겠습니다. 이러한 모든 과정이 손쉽게 이루어지는 것입니다.
Figure 6 로그온한 사용자에 바인딩 (Close Figure 6)
strComputer = "atl-ws-01"

Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colItems = objWMIService.ExecQuery _
  ("Select * from Win32_Process Where Name = 'explorer.exe'")

If colItems.Count = 0 Then
  Wscript.Echo "No one is logged on to the computer."
Else
  For Each objProcess in colItems
    objProcess.GetOwner strUser,strDomain
  Next
End If

Const ADS_SCOPE_SUBTREE = 2

Set objConnection = CreateObject("ADODB.Connection")
Set objCommand = CreateObject("ADODB.Command")
objConnection.Provider = "ADsDSOObject"
objConnection.Open "Active Directory Provider"
Set objCommand.ActiveConnection = objConnection

objCommand.Properties("Page Size") = 1000
objCommand.Properties("Searchscope") = ADS_SCOPE_SUBTREE

objCommand.CommandText = "SELECT displayName FROM " & _
  "'LDAP://DC=wingroup,DC=fabrikam,DC=com' WHERE " & _
    "objectCategory='user' " & _
    "AND samAccountName = '" & strUser & "'"
Set objRecordSet = objCommand.Execute

objRecordSet.MoveFirst

Do Until objRecordSet.EOF
  Wscript.Echo objRecordSet.Fields("displayName").Value
  objRecordSet.MoveNext
Loop
자, 그럼 오늘의 성과는 무엇일까요? (여담이지만 Microsoft 직원들의 말투가 이런 식입니다. Scripting Guy는 "모든 이해 관계자의 성과, 작업 항목, 불필요한 사항을 우선 순위별로 나누어 보아야 해"와 같은 말에 진절머리가 나 있죠.) 일단 로컬 컴퓨터나 원격 컴퓨터에 로그온한 사용자에 대한 정보를 얻는 방법을 배웠습니다. 그리고 혹시 과거로 돌아가 제2차 세계 대전에 참전하게 되면 "누구냐?"라는 질문에 대답할 수 있도록 이 칼럼을 복사하고 월드 시리즈 우승 팀 목록을 준비해야 한다는 사실도 배웠습니다. 뭐, 꼭 이런 경우가 아니더라도 언제 "1903 월드 시리즈 우승 팀은?"이라는 질문을 받을 지 모르는 일이니까요.
참고로 답은 보스턴 레드삭스입니다. 최초로 월드 시리즈 우승을 차지한 해이죠. 그렇다면 1904 월드 시리즈는 누가 우승했을까요? 모르겠다고요? 흠, 그렇다면 FBI에 신고를 할 수 밖에 없겠습니다.

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


 Security Watch: Windows의 PKI 기능 향상
Security Watch
Windows의 PKI 기능 향상
John Morello
이 칼럼은 Windows Server 2008의 시험판 버전을 기준으로 작성되었습니다. 이 문서에 수록된 모든 정보는 변경될 수 있습니다.

Windows 2000 릴리스 이후 Windows에서는 플랫폼 전반에 걸쳐 PKI(공개 키 인프라)를 지원하고 있습니다. Windows 2000에는 네이티브 인증 기관 기능이 처음으로 포함되었고 자동 등록 기능이 도입되었으며 스마트 카드 인증이 지원되었습니다. Windows XP와 Windows Server 2003에서는
이러한 기능이 더욱 향상되어 버전 2 인증서 템플릿과 사용자 인증서 자동 등록 지원 등을 통해 더욱 유연한 등록 옵션을 제공합니다. Windows Vista®와 Windows Server® 2008(이전 코드 이름 "Longhorn")에서는 고급 알고리즘, 실시간 유효성 검사, 관리 효율성 향상을 통해 Windows® PKI 플랫폼이 한 차원 더 강화되었습니다. 이 칼럼에서는 Windows Vista와 Windows Server 2008의 새로운 PKI 기능에 대해 설명하고 이를 활용하여 비용을 절감하고 보안을 향상시키는 방법에 대해 알아보겠습니다.
Windows Vista와 Windows Server 2008의 PKI는 암호화, 등록, 관리 효율성, 해지의 네 가지 핵심 영역을 중심으로 기능이 향상되었습니다. 이러한 자체적 기능 향상 외에도 Windows PKI 플랫폼은 더욱 간편하게 새 CA(인증 기관)를 만들고 배포할 수 있게 해 주는 역할 관리자 등의 고급 운영 체제 기능도 활용합니다. 또한 Windows Vista에서 스마트 카드를 사용하여 EFS(파일 시스템 암호화) 키를 저장할 수 있는 것처럼 Windows의 다른 여러 영역에서도 PKI 플랫폼의 향상된 기능을 활용할 수 있습니다.

암호화
암호화는 두 가지 면에서 기능이 향상되었습니다. 첫째, Windows는 이제 CNG(차세대 암호화)를 통해 프로토콜에 독립적이며 플러그 가능한 암호화 기능을 제공합니다. 이 기능을 사용하면 개별 알고리즘을 프로그래밍 방식으로 더 쉽게 개발하고 액세스할 수 있습니다. 둘째, CNG는 2005년 NSA(미국 국가 안전 보장국)에서 채택한 Suite B 알고리즘을 지원합니다.
CNG는 Microsoft 제품의 새로운 핵심 암호화 인터페이스이며 향후 출시되는 Windows 기반 암호 인식 응용 프로그램의 API로 권장됩니다. CNG는 더욱 간편한 알고리즘 검색 및 대체 기능, 교체 가능한 난수 생성기, 커널 모드 암호화 API를 비롯하여 개발자를 위한 다양한 새 기능을 제공합니다. 뿐만 아니라 CNG는 이전 버전인 CryptoAPI 1.0에서 제공하는 일련의 알고리즘과도 완벽하게 호환됩니다. 현재 일부 플랫폼을 대상으로 한 FIPS(Federal Information Processing Standards) 140-2 Level 2 인증 및 공통 기준에 대한 CNG 평가가 진행 중에 있습니다.
CNG Suite B는 AES(모든 키 크기), SHA-2 계열의 해시 알고리즘(SHA-256, SHA-384 및 SHA-512), ECDH(Elliptic Curve Diffie-Hellman), NIST(미국 국립 표준 기술원) standard prime curves P-256, P-384, P-521의 ECDSA(Elliptic Curve Digital Signature Algorithm) 등 모든 필수 알고리즘을 지원합니다. NSA에서는 인증된 Suite B 암호화 알고리즘이 '최고 기밀(Top Secret)'과 '기밀(Secret)'로 분류된 정보, 그리고 과거에는 '중요하지만 기밀은 아님(Sensitive-But-Unclassified)'으로 명시되던 개인 정보를 보호하는 데 사용될 것이라 밝혔습니다. 모든 Suite B 알고리즘은 공개적으로 개발되었으며 일부 다른 국가의 정부에서도 이 알고리즘을 국가 표준으로 채택하는 방안을 검토하고 있습니다.
Windows PKI 플랫폼의 하위 수준에 대한 이러한 개선 덕분에 개발자들은 더 안전하게 데이터를 보호할 수 있으며 시간이 지남에 따라 더 효율적으로 관리 및 개선할 수 있는 하위 시스템을 구축할 수 있습니다. CNG는 플러그 가능한 아키텍처이므로 필요에 따라 새 알고리즘을 추가할 수 있으며 CNG는 응용 프로그램 계층에서 이러한 알고리즘 공급자를 추상화합니다. 결론적으로 Windows Vista와 Windows Server 2008은 PKI 지원 응용 프로그램과 서비스를 개발하는 데 필요한 발전 가능한 고급 플랫폼을 제공하도록 설계되었습니다.

등록
Windows의 인증서 등록 환경은 새로운 마법사 방식의 등록 도구, 향상된 인증서 만료 처리 기능, 새로운 API "대신 등록" 기능, 자격 증명 로밍 등을 통해 크게 향상되었습니다. 이러한 향상된 기능을 통해 사용자에 미치는 영향을 최소화하면서 조직 전체에 인증서를 배포하는 과정을 중앙에서 더욱 간편하게 관리함으로써 PKI의 총 소유 비용을 절감할 수 있습니다.
등록 측면에서 가장 주목할 변화는 그림 1과 2의 새로운 인증서 등록 사용자 인터페이스입니다. 이 사용자 인터페이스는 등록 프로세스에서 사용자의 데이터를 입력할 수 없었던 기존의 제한적 인터페이스를 대체합니다. 새 인터페이스에서는 관리자가 데이터 입력을 요구하도록 인증서 템플릿을 구성한 경우 사용자가 등록 중에 데이터를 입력할 수 있습니다. 또한 이 인터페이스에서는 사용자가 지정된 템플릿에 등록할 수 없을 경우 그 이유를 명확하게 설명합니다.
그림 1 사용 가능한 인증서 선택
그림 1 사용 가능한 인증서 선택
그림 2 사용할 수 없는 인증서 상태 정보
그림 2 사용할 수 없는 인증서 상태 정보
등록 인터페이스의 또 다른 중요한 개선은 인증서 만료를 처리하는 방식에 있습니다. 새 인터페이스에서는 어떤 인증서가 언제 만료되는지에 대한 명확한 정보를 제공하며 사용자가 쉽게 인증서를 갱신하거나 경고 알림을 해제할 수 있게 해 줍니다. 관리자가 자동 등록을 통해 인증서를 자동으로 새로 고칠 수도 있지만 이 경고 기능은 이따금 회사 네트워크에 로그온하는 모바일 사용자 또는 연결이 끊어진 사용자에게 인증서 만료 날짜가 가까워졌음을 알리는 경우에는 중요합니다.
인증서 등록 기능을 사용하여 작업하는 개발자는 ActiveX® 기반 컨트롤(xenroll.dll 및 scrdernl.dll)에 비해 훨씬 향상된 기능을 제공하는 새로운 API를 사용할 수 있습니다. 이 새로운 인증서 등록 API는 훨씬 쉽게 이해하고 코딩할 수 있는 잘 정의된 클래스 계층 구조를 제공합니다. 이 새로운 API는 Windows Vista와 Windows Server 2008에서 xenroll을 대체합니다.
이러한 API의 변화는 개발자와 IT 전문가 모두에게 영향을 주는데, 그 이유는 Windows Vista 클라이언트에서 Windows Server 2003의 웹 기반 등록 기능을 사용할 수 없기 때문입니다. 즉, Windows Server 2003의 등록 페이지(기본적으로 /certsrv라는 가상 디렉터리에 저장됨)에는 Windows Vista에서는 더 이상 제공되지 않는 xenroll 컨트롤이 사용되기 때문입니다. 기술 자료 문서 "Windows Vista에서 인증서 서비스 웹 등록 페이지를 사용하는 방법"(support.microsoft.com/kb/922706)에는 이 문제에 대한 해결 방법이 설명되어 있습니다. 한편, Windows Server 2003에서 Windows Vista로의 자동 등록은 영향을 받지 않습니다.
이전 버전의 Windows Server에서 등록 에이전트가 대신 등록할 수 있는 범위에는 제한이 없었습니다. 달리 말해, 등록 에이전트 기능을 부여받은 사용자는 포리스트에 있는 다른 모든 사용자를 대신하여 등록을 수행할 수 있었습니다. 물론 이것은 해당 사용자가 기존 사용자를 대신하여 등록하고 새로 생성된 인증서로 기존 사용자를 가장하는 방법으로 자신의 권한을 쉽게 상승할 수 있음을 의미합니다. 이러한 위험을 방지하기 위해 등록 에이전트 기능은 가장 신뢰할 수 있는 사용자에게만 제공되었습니다. 이러한 배포 모델을 사용하면 보안은 향상되는 반면에 다른 사용자를 대신하여 등록할 수 있는 기능이 소수의 사용자에게만 집중되므로 유연성이 낮아지는 결과를 초래합니다. 따라서 여러 지역에 분산되어 있는 대규모 조직에서는 스마트 카드의 경우와 같이 최종 사용자에게 인증서를 배포하는 작업이 더욱 복잡해졌습니다.
Windows Server 2008에서는 등록 에이전트를 훨씬 더 세밀한 수준으로 제한할 수 있습니다. 그림 3에서 볼 수 있듯이 대신해서 등록할 수 있는 사용자 또는 대신해서 등록할 수 있는 템플릿을 기준으로 제한을 설정할 수 있습니다. 예를 들어 조직에서는 특정 지역 사무실의 IT 전문가가 담당 지역의 모든 사용자를 대신하여 등록할 수 있지만 인사 부서의 사용자는 대신할 수 없도록 설정할 수 있습니다. 등록 에이전트의 기능을 이와 같이 세분화하면 조직 전반에 걸쳐 등록 기능을 더욱 안전하고 효과적으로 위임할 수 있습니다.
그림 3 등록 에이전트의 기능 제한
그림 3 등록 에이전트의 기능 제한
PKI 관리에서 가장 까다로운 작업 중 하나는 조직 내 장치에 분산되어 있는 모든 키 쌍을 관리하는 것입니다. 어느 정도 복잡한 PKI 환경에서도 사용자가 로그온 위치에 관계없이 서로 다른 키 쌍(EFS, 무선 네트워크 인증, S/MIME 등의 용도)을 여러 개 사용할 수 있어야 하는 경우가 있습니다. 모바일 컴퓨팅과 터미널 서비스 사용이 점차 늘어나면서 로그온 위치에 관계없이 사용자가 사용할 수 있도록 이러한 키 쌍을 네트워크에 복제하는 것이 더욱 중요해지고 있습니다. 스마트 카드와 같이 사용자가 휴대하는 토큰은 이러한 문제의 일부를 해결하는 데 도움이 되지만 조직에는 이러한 카드가 없거나 인증서를 카드에 저장하지 않은 사용자들이 있게 마련입니다. 자격 증명 로밍을 사용하면 이러한 키 쌍과 인증서를 Active Directory®에 안전하게 저장하여 사용자의 로그온 위치에 관계없이 제공함으로써 이러한 문제를 해결할 수 있습니다.
Windows Server 2003 SP1에서 처음 제공된 자격 증명 로밍을 사용하면 로밍 사용자 프로필을 사용하지 않고도 컴퓨터 간에 인증서와 키를 안전하게 로밍할 수 있습니다. Windows Vista와 Windows Server 2008에는 이러한 기능이 기본적으로 포함되어 CSC(인증서 서비스 클라이언트) 서비스로 구현됩니다. 로밍할 수 있는 인증서와 충돌 조정 방법 등의 구성 옵션은 그룹 정책을 통해 관리됩니다. Windows Vista와 Windows Server 2008에서 CSC 서비스는 저장된 사용자 이름과 암호도 로밍할 수 있습니다. 자격 증명 로밍 기능은 Windows Vista에 기본으로 포함되어 있지만 Windows XP에서 Windows Server 2003 도메인 컨트롤러에 로그온하는 경우에도 완벽하게 지원됩니다(업데이트 배포 시 support.microsoft.com/kb/907247 참조). 즉, Windows Vista 배포가 완료될 때까지 기다리지 않아도 이 기술을 사용할 수 있습니다.

관리 효율성
Windows Server 2008에서는 CA(인증 기관) 서비스를 간편하게 구성 및 모니터링하고 가용성이 뛰어난 방식으로 실행하여 CA의 관리 효율성을 향상시키도록 하는 다양한 업그레이드가 이루어졌습니다. 첫째, CA 설정이 역할 관리자 도구에 통합되어 CA 서비스 설치 방법이 더욱 간결해졌습니다. 또한 프로세스의 각 단계에 기본값이 정의되어 이제 설정 작업을 무인 모드로 실행할 수 있습니다. 마지막으로 진단 기능이 향상되어 설정 과정에서 발생할 수 있는 오류 또는 문제를 더욱 쉽게 해결할 수 있습니다.
Windows Server 2008에서는 CA 서비스 모니터링 기능이 대폭 향상되었으며 Windows Vista에서도 인증서 진단 기능이 전반적으로 향상되었습니다. 전체 프로젝트에 관련되는 이벤트 생성 인프라의 유연성이 크게 향상된 것 외에도 기본 제공 모니터링 콘솔이 포함된 CA 서비스에서 Systems Center Operations Manager 2007(이전의 MOM)과 연결하여 엔터프라이즈 수준의 알림 기능을 제공합니다. 엔터프라이즈 PKI 모니터링 콘솔은 Windows Server 2003 AdminPak에 포함된 이전 버전보다 더욱 향상된 기능을 제공합니다. 이 새 콘솔은 제품 자체에 포함되어 이제 해당 포리스트의 모든 CA뿐만 아니라 OCSP(온라인 인증서 상태 프로토콜) URI를 모니터링합니다.
Operations Manager 관리 팩은 기본 제공되는 임계값 기반 알림 기능을 포함하여 조직의 PKI에 대한 패시브 모니터링 기능을 제공합니다. 예를 들어 이 관리 팩을 사용하면 CRL(인증서 해지 목록)의 해지 유효 시간을 모니터링하여 CRL이 해당 만료 날짜 이전의 특정 일 또는 시간에 도달할 때 PKI 관리자에게 알림을 보낼 수 있습니다. 마지막으로 CA 서비스 자체의 전반적 성능을 모니터링하여 문제를 해결하는 데 사용할 수 있는 새로운 성능 카운터가 다수 제공됩니다. 이러한 카운터는 초당 발급되는 인증서 수와 같은 데이터를 캡처하는 데 사용할 수 있습니다.
Windows Server 2008에서는 CA 서비스의 하드웨어 수준 클러스터링 지원이라는 새로운 기능이 제공됩니다. 이 클러스터 지원 기능은 표준 Microsoft Cluster Service(MSCS) 기술을 활용하며 2노드 액티브/패시브 구성을 지원합니다. 클러스터 지원 기능을 활용하면 발급 인프라의 가용성을 매우 높은 수준으로 유지할 수 있습니다. 클러스터 지원 기능은 지리적으로 다양하게 분산된 클러스터링 배포 환경에 사용할 수 있습니다. 클러스터링 지원 기능을 사용하려는 경우 단순히 CA를 클러스터링하는 것으로는 전체 PKI에 대한 가용성을 확보할 수 없다는 점에 주의해야 합니다. 클러스터링은 CA 자체의 가용성을 확보하는 데는 도움이 될 수 있지만 정상적으로 작동하는 PKI에는 CA에 직접적으로 의존하여 실행되지 않는 다른 구성 요소가 있을 수 있습니다. 예를 들어 CDP(CRL 배포 지점)와 OCSP 응답자의 가용성은 반드시 높은 수준으로 유지되어야만 해지가 올바르게 수행될 수 있습니다. 또한 HSM(하드웨어 보안 모듈), 특히 네트워크 기반의 HSM을 사용할 경우 이러한 모듈은 PKI에서 잠재적으로 장애 지점이 될 수 있습니다. 클러스터링은 인증 기관 자체의 가용성을 높일 수 있는 강력하고 새로운 기능이지만 전체 PKI 환경의 가용성까지 모두 높여줄 수 있는 만능의 처방은 아닙니다.

해지
CRL은 오랫동안 인증서의 유효성 검사에 사용되어 왔습니다. 이러한 CRL에는 아직 만료되지는 않았지만 더 이상 유효성을 신뢰할 수 없는 모든 인증서의 일련 번호가 들어 있습니다. 예를 들어 한 직원이 가진 인증서의 만료 날짜가 2008년 12월 31일인데, 이 직원이 2007년 9월 1일자로 퇴사한 경우 해당 인증서의 일련 번호는 CRL에 기록됩니다. 이 CRL은 HTTP 및 LDAP(Lightweight Directory Access Protocol) 경로와 같은 여러 CDP(CRL 배포 지점)에 제공됩니다.
CRL은 여전히 널리 사용되고 있지만 몇 가지 중요한 단점을 갖고 있습니다. 첫째, CRL은 CA에 의해 주기적으로(일반적으로 하루 1~2회) 게시됩니다. 클라이언트는 이 CRL을 다운로드하여 다음 게시 기간까지 캐시합니다. 그런데 이 캐시된 기간 중에 인증서가 해지될 경우 클라이언트는 다음 게시 때까지는 최신 상태를 알 수 없게 됩니다. 둘째, 규모가 매우 큰 조직의 경우 CRL의 크기도 매우 커질 수 있습니다(경우에 따라 100MB 이상). 이러한 크기의 파일을 널리 분산된 대규모 네트워크에 배포하는 작업은 쉽지 않을 뿐만 아니라, 특히 대역폭이 제한되어 있는 지역 사무실 등의 환경에서는 배포가 불가능할 수도 있습니다.
이러한 문제를 해결하기 위해 OCSP가 개발되어 RFC 2560으로 정의되었습니다. OCSP는 인증서의 상태를 실시간으로 검사하는 방법을 제공합니다. OCSP 클라이언트는 리프 인증서의 유효성을 검사해야 하는 컴퓨터에서 실행됩니다. 그런 다음 클라이언트 소프트웨어는 OCSP 응답자를 참조하여 리프 인증서의 유효성 상태를 문의하는 메시지를 보냅니다. 응답자는 해당 인증서의 유효성을 검사하여 결과를 클라이언트에 실시간으로 알려 줍니다. 이 방식을 사용하면 캐싱 및 배포 문제를 피할 수 있습니다.
Windows Vista에서 처음으로 제공되는(이전에는 타사 소프트웨어가 필요했음) OCSP 클라이언트 기능은 그룹 정책을 통해 구성할 수 있습니다. 기본적으로 Windows는 OCSP를 사용하려고 시도하며 응답자를 사용할 수 없는 경우에는 표준 CRL 조회 방식으로 변경합니다.
Windows Server 2008에서는 OCSP 응답자가 제공되어 이러한 요청에 응답합니다. 응답자는 역할 관리자를 통해 설치되며 Operations Manager 2007 관리 팩으로 모니터링할 수 있습니다. 클라이언트와 응답자 모두 OCSP 표준을 따르기 때문에 이와 유사한 표준 기반의 타사 구성 요소를 사용하는 기존 OCSP 환경에 쉽게 통합할 수 있습니다. 예를 들어 Windows Vista 클라이언트가 타사 응답자를 대상으로 인증서 상태를 확인하고 Windows Server 2008 응답자가 타사 클라이언트 응용 프로그램의 쿼리에 응답하는 기능이 모두 완벽하게 지원됩니다. 또한 Windows OCSP 응답자는 모든 표준 호환 CA에서 발급한 인증서 요청에 응답할 수 있습니다. 반드시 Windows Server 2008 CA(일반적으로 Windows 기반 CA)가 필요하지는 않습니다.

결론
Windows Vista와 Windows Server 2008의 PKI 플랫폼은 더욱 적은 비용으로 더욱 안전하게 PKI를 배포하고 운용할 수 있게 해 주는 몇 가지 새로운 기능과 수많은 향상된 기능을 제공합니다. 개발자들은 새로운 CNG API를 기반으로 더욱 손쉬운 프로그래밍 환경을 구현하고 새로운 암호화 표준 지원할 수 있습니다. 등록 기능 개선을 통해 조직에서는 간편하게 대량으로 인증서를 제공할 수 있고 조직 전반에 걸쳐 안전하게 키를 로밍할 수 있습니다. 또한 새로운 관리 팩과 CA 클러스터링 기능을 통해 더욱 편리하게 CA의 상태를 모니터링하고 가용성을 높은 수준으로 유지할 수 있습니다. 마지막으로, 향상된 해지 검사 기능을 통해 CRL 배포에 대역폭을 낭비할 필요 없이 표준 기반의 방식으로 인증서의 유효성을 실시간으로 검사할 수 있습니다. 결과적으로 Windows Vista와 Windows Server 2008은 Windows PKI 플랫폼을 한 차원 더 높은 수준으로 발전시켰습니다.
PKI 기능 향상 리소스
  • Windows PKI 홈 페이지
  • Windows Vista의 PKI 문제 해결
  • 차세대 암호화 API
  • 인증서 등록 API Windows Vista에서 인증서 서비스 웹 등록 페이지를 사용하는 방법
  • 인증서 서비스 클라이언트 - 자격 증명 로밍 구성 및 문제 해결

John Morello는 2000년부터 Microsoft에서 일했습니다. 수석 컨설턴트로서 Fortune 100대 기업과 미국 민간 및 군사 부문 고객을 위한 보안 솔루션을 설계하였으며, 현재는 Windows Server 그룹의 수석 프로그램 관리자로 보안 및 원격 액세스 기술을 담당하고 있습니다. Morello가 속한 팀의 블로그(blogs.technet.com/WinCAT)도 살펴보시기 바랍니다.


 The Desktop Files: RDP 익히기
The Desktop Files
RDP 익히기
Wes Miller

RDP(원격 데스크톱 프로토콜)를 사용하면 시스템을 원격으로 액세스할 수 있습니다. 매우 유용한 이 기술 덕분에 지난 몇 년간 시스템 관리자의 업무 부담을 상당히 줄일 수 있었습니다. RDP의 원격 액세스 지원 기능은 오랜 기간에 걸쳐 꾸준히 향상되었습니다. 1998년 Windows NT 4.0 Terminal Server Edition(TSE)에 처음 도입된 이후
거의 모든 Windows® 버전에서 발전을 거듭해 온 것입니다.
Windows 2000이 출시된 이후에는 누구나 간편하게 원격으로 서버 시스템에 액세스할 수 있게 되었습니다. 선택적 Windows 구성 요소로 포함된 터미널 서비스를 구성하여 시스템을 실제 터미널 서버로 사용하거나 현재 원격 데스크톱이라고 부르는 용도로 사용할 수 있었기 때문입니다. Windows Server® 2003과 Windows XP에서는 기본 원격 데스크톱 기능을 제공하여 사용자가 시스템을 로컬 시스템처럼 제어할 수 있게 해 줍니다. 현재 필자는 매일 원격 데스크톱 기능을 사용하여 집에 있는 PC와 서버를 원격으로 액세스하고 Media Center Extender도 사용하고 있습니다.
Windows XP와 이후의 Windows 버전에는 원격 데스크톱과 비슷하지만 로컬 사용자가 원격 사용자에게 지원을 요청할 수 있도록 설계된 원격 지원 기능이 추가되었습니다. 이와 같이 원격 액세스 지원 기능이 지속적으로 발전함에 따라 Windows Vista®에서는 이제 그룹 정책에서 허용하는 경우 원격 사용자가 원격 지원을 제공할 수 있습니다.
이 문서에서 자세하게 다루겠지만, 원격 데스크톱은 이처럼 강력한 기능을 더욱 새롭게 업그레이드하여 매우 유용한 여러 가지 기능을 제공합니다. 물론, 원격 데스크톱에도 몇 가지 제한 사항은 있지만 장점도 많습니다. 지금부터 이러한 제한 사항과 장점 모두를 살펴보겠습니다.

장단점 및 놀라운 기능
Windows XP(Media Center Edition 제외)의 주요 제한 사항은 대화형 사용자가 한 번에 한 명씩만 로그온할 수 있다는 것입니다. Windows XP의 빠른 사용자 전환을 사용하면 여러 사용자가 로그온할 수 있지만 PC의 로컬 또는 원격 사용자인지에 상관없이 마우스나 키보드를 사용하여 대화형 기능을 사용할 수 있는 사용자는 한 명뿐입니다. 터미널 서버로 실행되지 않는 Windows Server 버전의 경우 한 번에 두 개의 원격 데스크톱 세션을 연결할 수 있습니다. Windows Server 2003에서 원격 데스크톱을 통해 실제 콘솔 세션에 연결하려면 선택적 매개 변수 /console을 사용하여 터미널 서비스 클라이언트 응용 프로그램(MSTSC.exe)을 실행해야 합니다. 여기서 콘솔 세션은 매우 중요한데, 터미널 서비스 세션을 고려하여 적절하게 설계되지 않은 일부 오래된 응용 프로그램의 경우 콘솔 세션(세션 0)에만 대화 상자를 표시하는 경우가 많기 때문입니다. 그림 1에서는 Windows Server 2003의 콘솔 세션에 로그인한 사용자를 보여 줍니다. Windows XP 및 Windows Server 2003 원격 데스크톱은 라이선스를 적용하여 허용된 수의 사용자만 대화형 사용자로 로그온할 수 있게 합니다.
그림 1 세션 0에 로그인한 상태
그림 1 세션 0에 로그인한 상태
또한 네트워크 대역폭과 그룹 정책이 원격 데스크톱 환경에 영향을 줄 수 있습니다. Windows XP는 최대 24비트 해상도를 제공할 수 있을 뿐만 아니라 사운드, 로컬 프린터, 디스크 및 잘라내기/붙여넣기를 위한 클립보드를 리디렉션할 수도 있습니다. 원격 데스크톱의 화면 표시 방식으로 인해 원격 세션에서 그래픽 요소(테마, 배경 등)를 제거하면 사용 가능한 네트워크 대역폭이 크게 늘어나고, 그 결과 세션의 응답 속도가 훨씬 빨라집니다. Windows Vista에서는 이에 더하여 32비트 해상도와 추가 장치 리디렉션 기능을 제공합니다.
가장 좋은 원격 데스크톱 세션을 사용해도 대역폭이 부족하면 그래픽 처리가 많은 작업 등의 일부 작업은 실행하기 어려울 수 있으므로 적절히 계획을 세워야 합니다.

Windows Vista의 새로운 기능
Windows Vista에서는 원격 데스크톱이 상당히 변경되었습니다. 앞서 설명한 32비트 디스플레이 해상도와 글꼴 다듬기 기능은 이러한 두드러진 변화에 해당합니다. 그 외에도 /span 명령으로 터미널 서비스 클라이언트를 실행하여 Windows Vista 세션을 여러 모니터에서 실행할 수 있는 기능도 추가되었습니다. 이 경우 /span 명령은 Windows Vista 원격 호스트 시스템에만 작동하며 여러 대의 모니터에서 클라이언트의 해상도가 동일하고 모니터가 정렬되어 있어야 합니다. 이러한 확장은 원격 시스템(클라이언트)을 하나의 대형 디스플레이로 처리하는 방식으로 작동합니다. 따라서 응용 프로그램 창을 최대화하면 대화 상자가 잘못 배치되어 사용자가 직접 이동해야 하는 등의 예상치 못한 불편을 초래할 수 있습니다.
또한 연결을 시도하는 클라이언트가 Windows Vista 클라이언트이고 연결 대상 원격 시스템이 Windows Vista 시스템인 경우 사용자는 원격 세션의 사용자 인터페이스를 Windows Aero™ 투명 효과 모드로 실행할 수도 있습니다. 단, 이 경우 원격 시스템이 Aero 투명 효과를 지원하지 않아도 로컬 시스템은 반드시 이 모드를 지원해야 합니다. 이러한 효과는 클라이언트가 Windows Vista인 경우 Windows 원격 데스크톱의 아키텍처를 재구성하여 창 관리 작업 대부분을 클라이언트 시스템에서 수행함으로써 대역폭 사용을 줄이고 사용자 환경을 향상하는 데 따른 것입니다.
Windows Vista에는 또한 NLA(네트워크 수준 인증)라는 핵심 보안 향상 기능이 포함되어 있습니다. NLA를 사용하면 악의적 사용자가 서버를 스푸핑하여 사용자가 잘못된 서버에 연결하도록 하는 MITM(Man-In-The-Middle) 공격을 방지할 수 있습니다. 또한 NLA를 사용하면 인증을 위해 전체 Windows 사용자 인터페이스를 실행할 필요가 없기 때문에 원격 시스템에 미치는 영향이 최소화되고 서비스 거부 공격을 받을 가능성도 줄어들므로 인증 환경이 향상됩니다. 그러나 NLA를 사용하려면 클라이언트와 원격 시스템 모두 Windows Vista 시스템이어야 합니다. 그림 2에서는 RDP 6.0 클라이언트를 통해 인증 실행 여부, 경고 여부, 인증 필요 여부 등을 지정하는 방법을 보여 줍니다. Windows Vista 이전 버전의 Windows를 실행하는 원격 시스템에 연결하려는 경우에는 최소한 이러한 연결을 경고하도록 설정할 필요가 있습니다. 그렇지 않으면 연결이 실패하게 됩니다.
그림 2 고급 연결 기본 설정
그림 2 고급 연결 기본 설정
Windows Vista에서 또 다른 RDP 핵심 기능 향상은 바로 드라이브와 프린터 이외의 다른 리소스도 리디렉션할 수 있다는 것입니다. 원격 시스템에 드라이버가 설치되어 있고 해당 장치가 리디렉션을 지원하는 경우에는 스마트 카드를 비롯하여 다양한 새로운 유형의 장치를 리디렉션할 수 있습니다. 추가 장치 유형도 해당 공급업체를 통해 지원할 수 있습니다.
또한 Windows Vista에서는 RDP 6.0 클라이언트를 통해 게이트웨이 서버를 지원합니다. 따라서 사용자는 VPN 연결이나 타사 소프트웨어 없이도 인터넷을 통해 회사 시스템에 완벽하게 연결할 수 있습니다. 그림 3에서는 터미널 서비스 게이트웨이 서버 설정을 보여 줍니다. 게이트웨이 서버는 VPN과 비슷한 것으로 생각할 수 있으며 RDP 6.0 클라이언트 소프트웨어 외에는 별다른 클라이언트 소프트웨어가 필요하지 않습니다. VPN 설정이나 타사의 독점적 소프트웨어도 필요하지 않습니다.
그림 3 터미널 서비스 게이트웨이 서버 설정
그림 3 터미널 서비스 게이트웨이 서버 설정
Windows Vista에는 또한 RemoteApp™라는 새로운 기능을 위한 인프라도 제공합니다. RemoteApp는 어떤 경우에 유용할까요? 일반적으로 사용자는 원격 데스크톱을 통해 전체 Windows 세션에 연결할 수 있습니다. 그러나 사용자가 Microsoft® Word나 Microsoft PowerPoint®만 실행하려는 경우 RemoteApp를 사용하면 원하는 기능을 실행할 수 있습니다. Windows Server 2008에서는 강력한 응용 프로그램 공유 기능도 지원될 예정입니다.
또한 Windows Vista에는 Windows 데스크톱 공유 API를 위한 새로운 지원 기능이 추가되어 공유된 공동 작업 응용 프로그램을 게시할 수 있습니다. Microsoft 터미널 서버 팀이 만든 샘플 응용 프로그램(blogs.msdn.com/ts/ archive/2007/03/23/writing-a-desktop-sharing-application.aspx)을 보면 Windows 데스크톱 공유 API의 작동 방식을 확인할 수 있습니다.
Windows Vista 등에서 변경 사항 중 특히 기억해야 할 것은 세션 0(일반적으로 이전 응용 프로그램이 대화 상자 메시지를 표시하는 콘솔 세션)이 대개의 경우 사용자에게 액세스를 제공하지는 않는다는 점입니다. 그 결과 시스템 서비스(비대화형이지만 세션 0에서 실행됨)와 대화형 사용자 간의 대화형 작업이 줄어듭니다. 또한 Windows Vista에서 지나치게 권한이 높은 서비스 및 대화형 사용자로 인해 유발되는 공격 노출 영역을 줄일 수 있습니다. Windows Vista에서는 사용자 계정 컨트롤과 기타 보안 향상 기능을 통해 권한을 줄이는 데 중점을 두고 있습니다. Windows Vista에서 이전 소프트웨어를 실행하는 경우 해당 응용 프로그램을 설치할 때나 실행할 때 오류가 발생하지 않는다면 일반적으로 특별히 걱정할 문제는 없습니다.
원격 데스크톱을 지원하는 제품
원격 데스크톱과 관련하여 기억해야 할 것은 원격 데스크톱을 지원하는 제품이 무엇인지 확인하는 것입니다. Windows XP Professional, Media Center Edition 및 Tablet PC Edition과 Windows Server 2003의 모든 버전은 원격 데스크톱 기능을 제공합니다. Windows Vista의 경우 Business, Enterprise 및 Ultimate 버전에서 원격 데스크톱 기능을 제공합니다. Windows XP Home Edition을 포함한 Windows의 Home Edition과 Windows Vista의 모든 Home Edition에서는 원격 데스크톱 기능을 제공하지 않습니다.

터미널 서비스 클라이언트
새로운 RDP 6.0 클라이언트는 go.microsoft.com/fwlink/?LinkId=91612에서 다운로드할 수 있습니다. 앞서 살펴본 것처럼 이 클라이언트에는 RDP 6.0(Windows Vista 또는 Windows Server 2008) 시스템에 연결하는 데 필요한 모든 기능이 포함되어 있습니다.
그림 4에서는 RDP 6.0 클라이언트를 보여 줍니다. MSTSC에서 향상된 한 가지 중요한 사항은 자격 증명을 캐시하는 기능입니다. Windows Vista에서 Windows Vista 또는 Windows Server 2008에 연결하는 경우에는 SSO(Single Sign-On)가 그룹 정책을 통해 지원됩니다.
그림 4 RDP 6.0 클라이언트
그림 4 RDP 6.0 클라이언트
MSTSC.exe의 6.0 버전에는 아래 나열된 것처럼 여러 가지 명령줄 매개 변수가 있습니다. 하나씩 살펴보겠습니다.
mstsc [<connection file>] [/v:<server[:port]>]
[/console] [/f[ullscreen]] [/w:<width>] [/h:<height>]
[/public] | [/span] [/edit "connection file"] [/migrate] [/?]
/v:<server[:port]> 연결하려는 원격 컴퓨터와 선택적 포트 값을 지정합니다. 기본값인 포트 3389는 모든 버전의 Windows에서 변경할 수 있습니다.
/console 이전 버전 Windows의 콘솔 세션에 연결할 수 있습니다. 그러나 이 설정은 Windows Vista 또는 Windows Server 2008에는 사용할 수 없습니다.
/f 원격 데스크톱 연결을 전체 화면 모드로 시작합니다.
/w:<width> 원격 데스크톱 연결 창의 너비를 지정합니다.
/h:<height> 원격 데스크톱 창의 높이를 지정합니다.
/public 원격 데스크톱 연결을 공개 모드로 실행합니다. 공개 모드에서는 RDP 클라이언트가 데이터를 로컬 시스템에 캐시하지 않습니다. 예를 들어 회의실에 있는 시스템에서 비즈니스 서버에 연결할 때 공개 모드를 사용할 수 있습니다.
터미널 서비스의 놀라운 기능
터미널 서비스 구성 요소의 뛰어난 기능을 활용하는 Microsoft의 두 가지 기술이 있다는 것을 잘 모르는 독자도 있을 것입니다. Windows XP와 Windows Vista에서 제공하는 빠른 사용자 전환 기능을 사용하면 여러 사용자가 동일한 시스템에 로그온할 수 있으며 이들 사용자가 로그오프하지 않고도 사용자 컨텍스트를 빠르게 전환할 수 있습니다. Windows Media Center Edition과 Windows Vista에서는 이러한 인프라를 기반으로 하여 사실상 오디오/비디오 렌더링 기술과 코덱이 포함된 씬 클라이언트 터미널인 Media Center Extender가 유선 또는 무선 연결을 통해 로그인하여 원격으로 텔레비전에 Media Center 환경을 렌더링할 수 있도록 지원합니다. Windows XP의 경우 이 두 가지 기능은 시스템이 도메인에 연결되어 있지 않고 빠른 사용자 전환이 설정되어 있어야 하기 때문에 일반적으로 비즈니스 환경과는 관련이 없습니다. 이와 같이 비즈니스 환경에서 주로 사용되지는 않지만 두 기능 모두 Windows Vista의 Business 버전에서 지원됩니다. 이 문서에서는 이 기능에 대해 자세히 다루지 않겠습니다.

/span 원격 데스크톱의 너비와 높이를 로컬 가상 데스크톱과 맞추고 필요한 경우 이를 여러 모니터로 확장합니다. 모니터는 높이가 모두 같아야 하고 옆으로 나란히 정렬되어야 합니다.
/edit 지정된 .rdp 연결 파일을 편집할 수 있도록 엽니다. RDP 파일은 특정 원격 시스템의 연결 정보를 저장하는 데 사용됩니다.
/migrate 클라이언트 연결 관리자로 작성한 기존 연결 파일을 새로운 .rdp 연결 파일로 변환합니다.
MSTSC 클라이언트에서 향상된 많은 기능은 동일한 콘솔에서 터미널 서비스 ActiveX® 컨트롤과 다음에 설명할 TSMMC.msc를 사용하여 여러 시스템에 연결할 때도 사용할 수 있습니다.

Windows Server 2008의 새로운 기능
Windows Server 2008에는 지금까지 설명한 Windows Vista의 모든 기능과 변경 사항 외에도 터미널 서비스 웹 액세스 및 터미널 서비스 Easy Print와 같은 고유한 원격 데스크톱 기능이 포함되어 있습니다.
Terminal Services Web Access(터미널 서비스 웹 액세스)를 사용하면 원격 서버에서 RemoteApp로 설정된 프로그램의 목록을 웹 브라우저를 통해 확인할 수 있고 이러한 프로그램을 원격 데스크톱 ActiveX 컨트롤을 사용하여 한 번의 클릭으로 간편하게 실행할 수 있습니다. 어떤 면에서 이 기능은 필자가 지난달 Microsoft Desktop Optimization Pack에 대한 칼럼에서 설명한 SoftGrid 응용 프로그램 가상화 환경과 비슷하게 보일 수 있습니다. SoftGrid 응용 프로그램 가상화에서는 원격 사용자가 로컬에 소프트웨어를 설치할 필요 없이 응용 프로그램을 쉽게 실행할 수 있습니다. 향후 몇 년 동안 SoftGrid와 터미널 서비스 기술이 각각 어떤 상황에 사용되는지 비교해 보면 흥미로울 것입니다.
Terminal Services Easy Print(터미널 서비스 간편 인쇄)를 사용하면 원격(호스트) 시스템의 모든 프린터 작업을 로컬(클라이언트) 시스템으로 리디렉션할 수 있습니다. 이러한 작업은 이미 프린터 리디렉션으로도 구현되는 것으로 생각할 수 있지만 사실은 그렇지 않습니다. 터미널 서비스 Easy Print 기능을 사용할 때는 호스트 시스템의 추가 프린터 드라이버나 장치를 설치하기 위한 사용자의 대화형 작업이 필요 없습니다. 만약 로컬 프린터가 있으면 원격 시스템에서도 로컬과 마찬가지로 작동합니다. Terminal Services Easy Print(터미널 서비스 간편 인쇄) 기능을 사용하려면 원격 시스템에서 Windows Server 2008이 실행되어야 하며, 클라이언트 및 서버 시스템에는 Terminal Services 6.1 클라이언트가 실행되고 Microsoft .NET Framework 3.0 SP1이 설치되어 있어야 합니다. Terminal Services 6.1 클라이언트와 Microsoft .NET Framework 3.0 SP1은 Windows Server 2008이 릴리스될 즈음에 제공될 예정입니다.

원격 데스크톱 사용 팁
앞에서도 설명했듯이 필자는 원격 데스크톱을 매일 사용합니다. 보다 정확히 말하면 원격 데스크톱 Microsoft Management Console(MMC)이겠지요. 여기서 원격 시스템을 노드로 추가하면 동일한 사용자 인터페이스를 사용하여 여러 시스템 간에 쉽고 빠르게 전환할 수 있습니다. 그림 5에서는 MMC 환경의 예를 보여 줍니다. MMC 스냅인은 Windows Server 2003 관리 도구 팩의 일부로, 최신 버전은 go.microsoft.com/fwlink/?LinkId=91685에서 다운로드할 수 있습니다.
그림 5 MMC 페이지
그림 5 MMC 페이지
필자가 우연히 발견한 또 다른 흥미로운 팁은 바로 잘라내기와 붙여넣기에 관한 것입니다. 클라이언트와 서버에 걸쳐 적용되는 잘라내기 및 붙여넣기 기능은 Windows XP에서 처음 등장했습니다. 이 기능을 사용하려면 클라이언트와 서버 모두에 Windows XP가 실행되어야 하고 클립보드가 리디렉션되어야 합니다(그림 6 참조). Windows Vista 클라이언트는 또한 연결을 위해 클립보드 리디렉션이 설정된 경우에도 잘라내기 및 붙여넣기를 지원합니다.
그림 6 로컬 리소스 설정
그림 6 로컬 리소스 설정
또한 Ctrl+Alt+Delete와 같은 바로 가기 키는 인터넷을 통해 원격 시스템으로 전송되지는 않으며, 항상 로컬 시스템에 적용됩니다. Ctrl+Alt+Delete를 원격 시스템으로 보내려면 클라이언트에서 Ctrl+Alt+End를 누르십시오.
마지막으로 Microsoft 터미널 서비스 팀의 블로그(blogs.msdn.com/ts)를 정기적으로 확인할 것을 권하고 싶습니다. 필자는 이 블로그를 자주 방문합니다.
개인적으로 필자는 원격 데스크톱과 터미널 서비스를 사용한 이후 작업이 훨씬 편리해졌기 때문에 이제 이러한 기능이 없는 세상은 상상할 수조차 없게 되었습니다. 여기서 다룬 내용을 통해 여러분도 RDP 6.0 클라이언트와 Windows Vista 및 Windows Server 2008의 새로운 기능에 친숙해지셨기를 바랍니다.

이 칼럼을 작성하는 데 도움을 준 터미널 서비스 팀의 수석 프로그램 관리자 Nelly Porter에게 감사의 말을 전합니다.

Wes Miller는 텍사스 오스틴에 있는 Pluck(www.pluck.com)의 개발 관리자입니다. 이전에는 오스틴에 있는 Winternals Software에서 근무했으며 Microsoft에서 프로그램 관리자 및 Windows 제품 관리자로도 근무한 경력이 있습니다. 문의 사항이 있으면 technet@getwired.com으로 연락하시기 바랍니다.


 Field Notes: IM 면접
Field Notes
IM 면접
Nathan G. Jensen

최근 우리 회사에서는 선임 소프트웨어 엔지니어(재택 업무)에 대한 채용 공고를 온라인으로 게시했는데, 바로 전 세계에서 지원자가 밀려들었습니다. 수석 개발자로서 필자는 이 수많은 지원자들과 일일이 기술 면접을 실시해야 했습니다. 한숨을 쉬면서 긴 목록과 대조하며 한껏 과장된 이력서를 하나씩 추려 나갔습니다. 경험으로 미루어 볼 때 자격 미달인 지원자가 대부분이기 때문에 기술 면접이 필수적이라는 사실은 잘 알고 있었습니다.
하지만 엄청난 수의 지원자와 한 명씩 전화 면담을 한다면 한 달이 걸려도 못 끝내겠다는 생각이 들었습니다. 그런데 그 순간, 어둠 속에서 천사가 나타나 길을 밝혀 주는 것처럼 묘안이 하나 떠올랐습니다. "IM을 통해서 면접을 실시하면 되겠구나!"라는 생각이었죠. 정말 기발한 발상이었고, 멋지게 적중했습니다.
먼저 일반 전화를 사용하지 않고 Windows Live™ Messenger를 통해 심층 기술 면접을 실시할 것임을 알리는 전자 메일 메시지에 모든 지원자를 숨은 참조로 넣어 일괄로 보냈습니다. 이 전자 메일만으로도 지원자 중 절반이 이미 포기했습니다. 아마도 자신이 없어서 미리 포기한 것이겠죠. 직무와 관련된 기술적 질문에 대한 명확한 답을 원했기 때문에 나머지 지원자의 경우에도 IM 채팅이 훌륭한 면접 수단이 될 것이라 확신했습니다. 면접 과정이 이 정도 진행된 단계에서는 비기술적 자질이나 화술 등은 그다지 중요하지 않으니까요.
그림 두더지 잡기 식으로 IM 창을 여러 개 열어 놓고 모든 지원자에게 질문을 던짐
그림 두더지 잡기 식으로 IM 창을 여러 개 열어 놓고 모든 지원자에게 질문을 던짐
이때 가장 우선적으로 살펴본 것은 이러한 새로운 형태의 면접이 과연 시간과 비용을 절약해 줄 수 있는지 여부였습니다. 결론부터 말하자면, 전화비가 절감되는 것은 물론이고 지원자가 면접을 위해 접속하면서 여러 지원자를 동시에 효과적으로 처리할 수 있다는 사실도 알게 되었습니다. 정말 흥미로운 결과였죠. 두더지 잡기 식으로 IM 창을 여러 개 열어 놓고 모든 지원자에게 질문을 던졌습니다. 게다가 질문을 미리 만들어 두었기 때문에 복사해서 붙여 넣기만 하면 됐습니다.
인터넷에서 모범 답안을 찾아내 대답하지 못하도록 웹에 있는 내용은 피했습니다. 누군가가 잘 다듬어진 기사나 공식 문서에서 발췌한 듯한 대답을 올리면 확연하게 드러납니다. 또한 Windows Live Messenger에서는 각 대답이 게시된 시간을 추적할 수 있으므로 나중에 다시 검토하여 답변에 시간이 오래 걸린 지원자를 추려낼 수 있습니다.
동시 다발적인 IM 채팅을 절반 정도 진행했을 때 또 한번 무릎을 탁 치게 되는 순간이 있었습니다. 필자의 전화가 울린 순간이었죠. 면접을 진행하면서 동시에 다른 사람과 전화 통화도 할 수 있다는 걸 알게 된 것입니다. 이것이야말로 다중 스레드를 통한 효율성 확보의 절정이 아니겠습니까?
최고의 방법을 찾았다는 생각이 들 때쯤 장점을 하나 더 발견할 수 있었습니다. 전화를 통한 면접 시 가장 참기 어려운 순간은 짧은 질문에 지원자가 장황한 답변을 늘어놓는 때입니다. 그러나 IM을 사용하면 사람들이 간결하게 대답하는 경향이 있으므로 이러한 문제도 없었습니다.
각 면접이 끝날 때마다 나중에 기록된 내용을 검토하고 채용 여부를 판단할 수 있도록 채팅 로그를 저장했습니다. 뿐만 아니라 이렇게 저장된 로그는 상급자에게 보내 객관적인 비교를 부탁할 수도 있었습니다. 결과적으로 전 과정이 몇 주가 아니라 몇 시간 만에 끝났습니다. 전화 면접을 실시했다면 25명밖에 처리하지 못했을 시간에 말입니다.
이러한 놀라운 방법을 찾아낸 것이 매우 자랑스러웠습니다. 질문에 정확한 대답을 빠르게 내놓은 지원자를 선택했고, 이후 상급자가 보다 일반적인 전화 면접을 실시했습니다. 빠르고, 효율적이고, 생산적인 방법이었으며 결과적으로 직무에 적합한 지원자를 며칠 만에 찾을 수 있었습니다.

Nathan G. Jensen은 솔트레이크시티에서 수석 웹 개발자이자 자유 기고가로 활동하고 있습니다. 문의 사항이 있으면 builderdash.com을 방문하시기 바랍니다.


 Windows Confidential: Windows 탐색기에서 텍스트를 사용할 수 없는 이유
Windows Confidential
Windows 탐색기에서 텍스트를 사용할 수 없는 이유
Raymond Chen

예전에 Send To X PowerToy라는 도구가 있었습니다. 이 도구를 사용하면 파일을 여러 개 선택하여 마우스 오른쪽 단추로 클릭한 다음 Send To Clipboard as Names를 선택하여 파일 이름을 붙여 넣을 수 있습니다. 쉽게 예상할 수 있듯이 이 도구는 선택한 파일의 이름을 클립보드로 보냅니다.
확실히 유용한 PowerToy이기는 했지만, 왜 이런 도구가 필요했을까요? 처음부터 Windows® 탐색기에서 여러 파일을 복사한 다음 해당 파일의 이름만 텍스트로 붙여 넣을 수 있도록 하지 않은 이유는 무엇일까요? 또한 Windows 탐색기에서 마우스로 파일을 끌어서 메모장에 놓는 방법으로 파일 이름만 복사되도록 하지 않은 이유는 무엇일까요?
그렇게 하려고 해 보았지만 잘 되지 않았습니다.
클립보드를 통한 전송이든 끌어서 놓기 기능을 통한 전송이든 모든 데이터 전송은 IDataObject 인터페이스로 표시되는 OLE 데이터 개체를 통해 이루어집니다. 데이터 개체는 다양한 형식을 제공합니다. 텍스트와 비트맵을 비롯한 몇 가지 클립보드 형식은 Windows 초창기부터 지금까지 사용되고 있습니다. 그리고 시간이 지남에 따라 다른 형식이 추가된 것입니다. 파일을 끌어서 놓는 기능이 Windows에 처음 도입되었을 때는 HDROP의 형태였습니다. 예를 들어 DragQueryFile과 같은 함수에 파일을 전달하면 파일 이름을 추출할 수 있었습니다. Windows 탐색기에서 클립보드로 어떤 것을 복사한 경우 얻게 되는 데이터 개체는 앞서 언급한 HDROP, 파일 내용, 파일 그룹 설명자 등을 제공합니다. 그런데 이 데이터 개체가 제공하지 않는 형식 중 하나가 바로 텍스트입니다.
끌어온 것을 놓을 대상(끌어온 개체를 놓을 수 있는 위치)은 사용자가 해당 대상으로 끌어왔거나 끌어서 놓으려는 데이터 개체가 있다는 것을 알게 되면, 데이터 개체에게 '무엇을 갖고 있는지' 묻습니다. 데이터 개체는 자신이 지원하는 모든 형식을 우선 순위에 따라 나열하여 응답합니다. 즉, 해당 데이터 개체의 특징을 가장 잘 나타내는 형식이 가장 먼저 반환됩니다. 그런 다음 그 다음으로 중요한 형식이 순서대로 반환됩니다. 이러한 방식으로 원래 개체의 특징과 가장 거리가 먼 형식이 마지막에 반환됩니다. 예를 들어 Windows 탐색기 창 밖으로 끄는 개체를 나타내는 데이터 개체는 셸 ID 목록을 가장 먼저 제공할 것입니다. 그 이유는 Windows 탐색기 창의 내용을 거의 완벽하게 나타내는 형식이 셀 ID 목록이기 때문입니다. 그 다음으로 파일 그룹 설명자, 파일 내용, 그리고 HDROP가 순서대로 목록에 제공될 것입니다.
1998년에 셸 팀에서는 이 때 제공되는 형식 목록의 맨 끝에 일반 텍스트를 추가하려고 했습니다. 기본적으로 "정말로 필요한 경우 최소한 텍스트(즉, 파일 목록)라도 얻을 수 있도록 한다"는 취지에서 출발한 것입니다. 그런데 문제는 이러한 텍스트 형식에 이끌려 오작동을 일으키는 프로그램이 너무나도 많았다는 데 있습니다. 이러한 프로그램은 제시된 우선 순위는 무시하고 곧바로 텍스트 형식으로 이동하여 단순한 파일 목록을 그대로 사용했습니다. 결과적으로 Windows 탐색기에서 파일을 끌어서 특정 문서에 놓으면 파일 자체가 문서에 삽입되지 않고 단지 파일 이름만 삽입되는 현상이 나타났습니다.
어떻게 해야 했을까요?
응용 프로그램에 미치는 부정적인 영향이 너무 강했기 때문에 이 기능은 제거되었습니다. 따라서 Windows 탐색기에서 파일을 끌어서 다른 곳에 놓거나 Windows 탐색기에서 복사한 파일을 다른 곳에 붙여 넣을 때 셸 데이터 개체는 파일 이름을 텍스트로 제공하지 않습니다.
그러나 Windows Vista®에서는 경로를 텍스트로 복사할 수 있는 방법을 마련함으로써 이 오래된 문제를 바로잡았습니다. Shift 키를 누른 채로 마우스 오른쪽 단추를 클릭하면 확장된 상황에 맞는 메뉴가 표시됩니다. 이 메뉴에 '경로로 복사'라는 새로운 옵션이 나타납니다. 이제 PowerToy는 필요 없습니다.

Raymond Chen은 The Old New Thing 웹 사이트와 동명의 저서(Addison-Wesley, 2007)에서 Windows의 역사와 Win32 프로그래밍에 대해 다루고 있습니다. Chen은 운영 메커니즘 업무를 다른 사람에게 넘겼습니다.