WMI로 Windows 관리

WMI로 Windows 관리

Michael Maston
Microsoft Corporation

1999년 11월

요약: 규모가 커지고 복잡해지는 엔터프라이즈 시스템, 응용 프로그램 및 네트워크의 관리에 도움이 되도록 Windows 2000의 일부로 개발된 Microsoft® Windows® Management Instrumentation을 소개합니다. Windows 95, Windows 98 및 Windows NT® 4.0에서도 사용할 수 있습니다. (15 인쇄 페이지)

목차

소개
시스템의 모든 서비스 나열
소개 중지된 자동 서비스 나열
소개 사용 가능한 공간이 20% 미만인 모든 드라이브 파티션 나열
소개 운영 체제 부팅 지연 설정
소개 응용 프로그램 이벤트 로그 백업
소개 원격 컴퓨터 다시 부팅
소개 WMI를 통해 메모장 시작
소개 WMI에서 Windows NT 로그 이벤트 수집
소개 CPU 사용률이 높은 이벤트 수집
소개 결론

소개

이 기사의 목표는 Microsoft® Windows® Management Instrumentation(WMI)을 소개하고, WMI에 익숙해지고 가능한 빨리 실행하여 스크립트 인터페이스를 통해 시스템을 관리하는 데 WMI를 사용하도록 하는 것입니다. WMI를 사용하여 작업을 수행하기 전에 몇 가지 유용한 예제의 사용을 포함하여 WMI가 무엇인지, 사용 목적이 무엇인지, 귀중한 이유가 무엇인지에 등에 관해 약간의 배경 지식이 필요합니다.

정보 기술 관리자가 당면한 가장 큰 난제의 하나는 점점 규모가 커지고 복잡해지는 엔터프라이즈 시스템, 응용 프로그램 및 네트워크를 관리하는 것입니다. 이러한 문제의 해결과 Windows 기반 서버 및 데스크톱의 총 소유 비용 절감을 돕기 위해 Microsoft는 확장 가능 관리 인프라이며 Windows 2000의 일부로 제공되는 Windows Management Instrumentation(WMI)을 개발했습니다. WMI는 DMTF(Distributed Management Task Force)가 채택한 WBEM 권고안과 CIM(Common Information Model)에 기반합니다. http://www.msdn.microsoft.com/voices/news/wmisidebar2.asp 에서 "DMTF, CIM, WBEM 및 WMI" 막대를 참조하십시오. WMI에는 CIM에서 정의한 관리 개체는 물론 Windows 플랫폼에서 사용할 수 있는 추가 정보를 위한 CIM 모델 확장도 포함됩니다.

즉, WMI는 일관되고 확장 가능하며 표준에 기반하는 단일의 개체 지향 인터페이스를 사용하여 Windows 2000의 관리를 극대화합니다. 또한 WMI 데이터에 액세스하는 모든 응용 프로그램이나 스크립트는 로컬 컴퓨터에서 실행하든 원격에서 실행하든 관계없이 제대로 작동할 수 있습니다. WMI는 Windows 2000에는 물론 Windows 95, Windows 98 및 Windows NT® 4.0에도 사용할 수 있습니다. 오늘날 IT 관리자가 당면한 복잡한 관리 작업의 해결에 소중하게 사용할 수 있는 WMI의 핵심 기능은 다음과 같습니다.

• 균일 스크립트 API 모든 관리 개체는 CIM 개체 모델에 기초한 공통 개체 프레임워크에 정의됩니다. 스크립트는 단일 API인 WMI만 사용하여도 본질적으로 다른 많은 원본에서 정보를 액세스할 수 있습니다.
• 원격 관리 응용 프로그램과 스크립트는 WMI 내에서 관리되는 개체를 기본적으로 로컬과 원격 모두에서 사용할 수 있습니다. 원격 개체 관리에 추가 작업이 필요 없습니다.
• 검색성과 탐색성 응용 프로그램과 스크립트는 사용 가능한 클래스를 나열함으로써 시스템에 대한 사용 가능한 정보를 찾을 수 있습니다. 관련 개체 사이의 관계를 검색하고 교환하여 하나의 관리된 엔티티가 다른 엔티티에 미치는 영향을 알 수 있습니다.
• 쿼리 기능 WMI는 관리 데이터를 관계형 데이터베이스처럼 취급하며, 데이터를 필터링하고 관심 있는 데이터만을 중심으로 요청하기 위해 SQL 쿼리를 보낼 수 있게 허용합니다.
• 강력한 이벤트 게시 및 가입 내부 이벤트 기능의 지원 여부에 관계 없이 시스템에 있는 관리 개체의 거의 모든 변경 내용에 대해 이벤트를 요청할 수 있습니다. 이벤트 가입자는 원래 개발자가 미리 정의한 이벤트를 얻을 수 있을 뿐만 아니라 자신의 특정 관심에 따라 매우 특정한 이벤트를 알리도록 요청할 수 있습니다. 또한 아키텍처의 신축성이 매우 뛰어나므로 사실상 모든 사용자 정의 동작을 특정 이벤트 수신하는 즉시 수행할 수 있습니다.

우선 아키텍처 관점에서 WMI를 살펴보도록 합니다. 그림 1은 공급자, CIM 개체 관리자(CIMOM) 및 WMI 정보의 소비자 등으로 구성되는 WMI의 3계층 모델을 보여줍니다.

그림 1 WMI 아키텍처

가장 낮은 수준에서 상위 수준으로 작업해 나갈 때 첫째 계층에는 공급자가 있습니다. 간단히 설명해서 공급자는 운영 체제, 서비스, 응용 프로그램, 장치 드라이버 같은 관리 대상 시스템과 CIM 개체 관리자 사이의 중간 에이전트입니다. 공급자의 작업은 관리를 위해 소프트웨어가 제공하는 인터페이스를 사용하여 기본 데이터 원본에서 관리 정보를 추출하는 것입니다. 그런 다음 관리 정보와 인터페이스는 공급자에 의해 WMI가 WMI 소비자에게 제공하는 개체 클래스로 매핑됩니다. 나아가, 새롭게 업데이트된 관리 대상 시스템은 심각한 중간 변환 없이 관리 API를 노출하는 직접적인 방법으로 공급자를 사용합니다.

그 다음 층에는 자체의 저장 리포지토리를 가지며 개체 요청의 중개자 역할을 하는 CIM 개체 관리자인 CIMOM이 있습니다. CIMOM 및 그 리포지토리는 WinMgmt라는 시스템 서비스에 의해 시스템에 표현됩니다. 공급자는 게시된 COM 인터페이스 집합을 통해 CIMOM에 연결됩니다. CIMOM은 사용 가능한 클래스(정의는 리포지토리에 저장)와 그러한 클래스의 인스턴스를 공급할 책임이 있는 공급자를 추적합니다. WMI 소비자가 CIMOM에 관리 정보를 요청하면 CIMOM은 요청을 평가하고 정보를 가진 공급자를 확인한 다음 정보를 구하여 소비자에게 데이터를 제공합니다. 소비자는 필요한 정보를 요구만 하면 되고, 정확한 정보원이나 기본 API에서 정보가 추출되는 방법에 대한 세부 사항은 알 필요가 없습니다. 정적 데이터를 리포지토리에 저장하여 공급자 없이도 검색할 수 있지만, WMI 시스템의 실제 강점은 관리 대상 시스템에 대한 동적 정보를 제공하는 것이고 이러한 정보의 제공은 완전히 공급자를 통하여 이루어집니다.

마지막 층에는 WMI 데이터의 소비자가 있습니다. 소비자는 MMC 스냅인과 같은 관리 도구, Microsoft Systems Management Server(SMS), 다른 공급업체의 응용 프로그램 또는 스크립트와 같은 관리 응용 프로그램일 수 있습니다. 앞에서도 설명한 것처럼 이들 소비자는 정보가 필요한 개체의 클래스만 알면 됩니다. 정보의 출처와 실제로 정보를 얻는 방법에 대한 자세한 내용은 숨겨지며 관련이 없습니다. 이러한 방식에 따라 응용 프로그램이나 스크립트는 단일 공통 API인 WMI에 쓸 수 있고 컴퓨터, 운영 체제, 응용 프로그램, 장치에 대한 풍부한 정보는 물론 SNMP나 DMI 같은 다른 관리 프로토콜을 통한 정보도 얻을 수 있습니다.

WMI 사용 예제를 설명하기 전에 WMI가 제공하는 관리 클래스를 통해 수행할 수 있는 작업의 종류를 알아보기로 합니다. WMI 클래스에서 정의할 수 있는 정보에는 몇 가지 종류가 있습니다.

• 속성 클래스의 특정 인스턴스에 대한 설명 또는 운영 정보를 제공합니다. 예를 들어 Win32_DiskDrive 클래스의 인스턴스는 C: 드라이브에 값 "IDE"를 갖는 InterfaceType이라는 속성을 정의합니다.
• 메서드 클래스의 특정 인스턴스에서 메서드는 그 인스턴스를 대상으로 수행할 수 있는 동작입니다. 예를 들어, Win32_Directory 클래스에는 Windows 그래픽 사용자 인터페이스에서처럼 폴더의 내용을 압축할 수 있는 Compress() 메서드가 있습니다.
• 이벤트 시스템에서 발생한 관심 있는 사건이나 실패를 수신하기 위해 소비자가 요청할 수 있는 알림입니다. 정의된 속성의 변경 내용을 이벤트의 기초로 사용할 수 있습니다. 예를 들어, Win32_Processor 클래스의 LoadPercentage 속성은 CPU 사용률이 50% 이상으로 측정될 때마다 이벤트를 요청하기 위해 사용할 수 있습니다. 또한, 이벤트는 특정 속성에 기초하지 않고도 제공될 수 있습니다.
• 연결 연결은 클래스 사이의 관계를 설명하며 그 자체도 클래스에 의해 정의됩니다. 전화 접속 모뎀 및 그것이 연결된 통신 포트의 인스턴스에 대한 참조를 포함하는 Win32_POTSModemToSerialPort 클래스는 연결의 한 예입니다. 연결은 문제 해결과 같은 작업을 위해 관련 구성 요소의 전체 시스템에 대한 관리 정보를 보거나 교환할 수 있기 때문에 매우 강력한 개념입니다.

Windows 2000과 함께 제공되며 다른 모든 Windows 운영 체제에도 사용할 수 있는 최신 버전의 WMI에는 시스템의 많은 부분을 위해 풍부한 장치 정보를 제공하는 몇 가지 공급자가 포함되어 있습니다. 이들 공급자는 다음과 같습니다.

• Win32® 공급자 운영 체제, 컴퓨터 시스템, 주변 기기 및 파일 시스템에 대한 정보와 보안 정보를 제공합니다.
• WDM 공급자 사용자 입력 장치, 저장 장치, 네트워크 인터페이스 및 통신 포트를 위해 낮은 수준의 WDM(Windows Driver Model) 드라이버 정보를 제공합니다.
• 이벤트 로그 공급자 Windows NT 이벤트 로그 항목 읽기, 이벤트 로그 관리 옵션 구성 및 이벤트 로그 백업을 가능하게 합니다. 이벤트가 로그에 추가될 때 WMI 이벤트가 생성될 수 있습니다.
• 레지스트리 공급자 레지스트리 키 만들기, 읽기 및 쓰기를 가능하게 합니다. 지정한 레지스트리 키가 수정되면 WMI 이벤트가 생성될 수 있습니다.
• 성능 카운터 공급자 시스템 모니터 도구에 표시되는 성능 값의 계산에 사용되는 원시 성능 카운터 정보를 제공합니다. 시스템에 설치된 성능 카운터는 자동으로 이 공급자를 통해 나타납니다. Windows 2000에서만 지원됩니다.
• Active Directory® 공급자 Microsoft Active Directory 서비스에 저장되는 모든 정보의 게이트웨이의 역할을 합니다. 단일 API를 사용하여 WMI와 Active Directory 모두의 정보를 액세스할 수 있게 합니다.
• Windows Installer 공급자 Windows Installer에 대한 완전한 제어와 WMI를 통한 소프트웨어 설치를 가능하게 합니다. 또한 Windows Installer를 사용하여 설치된 모든 응용 프로그램에 대한 정보를 제공합니다.
• SNMP 공급자 관리에 SNMP(단순 네트워크 관리 프로토콜)를 사용하는 시스템과 장치의 게이트웨이 역할을 합니다. SNMP MIB 개체 변수를 읽고 쓸 수 있습니다. SNMP 트랩은 자동으로 WMI 이벤트에 매핑됩니다.
• 보기 공급자 기존 클래스로부터 새로운 집계 클래스를 만들 수 있습니다. 관심 있는 정보만을 위해 원본 클래스를 필터링할 수 있고, 여러 클래스의 정보를 단일 클래스로 조합할 수 있으며, 여러 컴퓨터의 정보를 단일 보기에 집계할 수 있습니다.

http://www.msdn.microsoft.com/voices/news/wmichart.asp 에서 WMI 시스템 스키마 차트를 참조하십시오. 이 스키마 차트는 Windows 2000에서 사용할 수 있는 중요한 WMI 시스템 클래스 및 장치 클래스와 더불어 각 클래스에서 정의하는 속성, 메서드 및 연결을 보여줍니다. 공급자에 대한 전체 스키마만으로도 여기에 모두 게시할 수 없을 정도로 방대하고 풍부합니다. 그러나 이 차트는 WMI가 제공하는 내용을 탐색할 때 유용한 참조 도구가 될 수 있고 사용할 수 있는 기능을 더 많이 배우기 위한 출발점으로 이용할 수 있습니다. 그러나 WMI 공급자는 단지 핵심 운영 체제 기능으로 제한되지는 않습니다. Windows 플랫폼에서 실행되는 다른 핵심 응용 프로그램과 서비스를 위해 Microsoft나 다른 공급업체에서 많은 공급자를 개발했습니다. http://www.msdn.microsoft.com/voices/news/wmisidebar1.asp 에서 "How others are making use of WMI(다른 사람들이 WMI를 사용하는 방법)" 세로 막대를 참조하십시오.

이제 WMI의 정의와 시스템 관리에 편리한 이유에 대해 설명이 끝났습니다. 이제부터는 WMI의 스크립트 지원을 사용하여 시스템을 관리하는 방법을 설명하기로 합니다. Windows 플랫폼의 스크립트처럼 Windows 스크립트 호스트(WSH)를 통해 여러 가지 스크립트 언어를 사용할 수 있습니다. 여기에는 Microsoft Visual Basic® Scripting Edition(VBScript), Microsoft JScript® 및 Perl 같이 Microsoft ActiveScripting 기술을 지원하는 스크립트 언어가 포함됩니다. C++, Visual Basic, ASP(Active Server Pages) 및 표준 HTML 페이지 안의 스크립트를 통해 쉽게 WMI 클래스를 액세스할 수 있습니다.

WMI 장치 정보를 사용하여 수행할 수 있는 작업은 너무 많기 때문에 모든 주요 하위 시스템의 대표적인 예를 이 기사에 제시할 수는 없습니다. 다행히 어느 한 클래스에서 클래스 액세스, 속성 읽기 및 쓰기, 메서드 실행 및 이벤트 수신 방법을 이해하면 그것을 다른 WMI 클래스에도 적용할 수 있습니다. WMI의 성능 일부를 설명하기 위해 VBScript로 작성한 몇 가지 예제를 선택했습니다. 예제는 다음과 같습니다.

• 설치된 모든 서비스의 목록을 열거한 다음 중지했지만 "자동" 시작 모드로 설정된 서비스만 확인합니다.
• 내 컴퓨터의 모든 논리 디스크 파티션을 나열하고 사용할 수 있는 공간이 20% 미만인 파티션을 확인합니다.
• 기본으로 선택된 운영 체제를 부팅하기 전에 시간 지연을 변경합니다.
• 내 "응용 프로그램" 이벤트 로그에서 백업을 수행한 다음 로그 파일을 지웁니다.
• 동료의 데스크톱 시스템을 다시 부팅합니다. 걱정할 필요는 없습니다. 동료가 이 작업 수행에 필요한 보안 사용 권한을 주어야 했고 이는 보안에 관해 논의할 기회가 되었습니다.
• WMI 메서드를 통해 메모장 유틸리티를 시작합니다.
• 이벤트 로그에 추가되는 새 이벤트를 감시할 이벤트 소비자를 설정합니다.
• CPU 사용률이 50%를 초과할 때마다 이벤트를 요청하도록 이벤트 소비자 스크립트를 다시 구성합니다.

시스템의 모든 서비스 나열

이 예제에서는 Win32_Service 클래스를 사용하여 시스템에 설치된 서비스를 실행 중인가의 여부에 관계 없이 모두 출력합니다.

Set ServiceSet =
GetObject("winmgmts:{impersonationLevel=impersonate}").InstancesOf("Win32_Service")
for each Service in ServiceSet
WScript.Echo Service.Description
Next

이 예제를 잠깐 살펴보면 각 단계에서 수행되는 작업을 이해할 수 있습니다. 먼저 WMI 서비스(WinMgmt)에서 GetObject()를 호출하여 개체를 요청합니다. 이를 위해서는 InstancesOf() 메서드를 통해 Win32_Service 클래스의 모든 인스턴스를 요청합니다. 이 호출의 결과로 Win32_Service 클래스의 인스턴스 목록이 반환됩니다.

인스턴스를 다시 ServiceSet 변수에 넣은 후에는 각 인스턴스를 차례로 거치면서 관심 있는 속성, 즉 서비스의 친숙한 이름이 포함되어 설명 필드를 표시합니다. 설명 속성은 서비스 개체의 자동화 속성으로 취급되므로 훨씬 직관적인 스크립트를 작성할 수 있습니다. 또한 AQL 쿼리를 ExecQuery() 메서드로 보내도 정확히 같은 결과를 얻을 수 있습니다.

Set ServiceSet =
GetObject("winmgmts:{impersonationLevel=impersonate}")
.ExecQuery("select * from Win32_Service")

이 SQL 쿼리에서는 선택되고 반환될 모든 인스턴스(인스턴스의 모든 속성 포함)를 요청합니다. 이 양식을 사용하더라도 반환되는 개체의 집합은 정확히 같지만, 아래의 예제에서 명확히 알 수 있듯이, 쿼리 양식을 이용하면 관심 있는 인스턴스로만 반환되는 속성, 인스턴스 또는 둘 다의 개수를 세밀하게 제어할 수 있습니다. 보다 중요한 것은 열거를 지원하는 WMI를 통해 제공되는 모든 클래스에 대해 이들 메커니즘 중 어느 것이나 사용할 수 있다는 것입니다.

이 예제 및 다음에 나오는 예제와 관련하여 마지막으로 주의할 것은 사용되는 보안 모델에 대한 것입니다. 바로 위에서 본 GetObject() 호출에 "{impersonationLevel=impersonate}" 문이 포함되어 있습니다. 기본적으로 이 문은 시스템이 데이터를 요청하거나 메서드를 실행할 때 제시될 자격 증명으로서 현재의 로그인 자격 증명을 사용하도록 시스템에 알립니다. 이렇게 하면 원시 API를 직접 호출하는 것과 같습니다. 이것은 로컬 컴퓨터와 원격 컴퓨터에 관계없이 모든 요청에 적용됩니다. 어느 경우든 시스템이 보는 사용자는 현재 로그인으로 정의된 사용자입니다. 물론, 필요하면 요청에 대한 다른 자격 증명을 지정할 수 있지만 이 기사에서는 그 내용을 다루지 않습니다. 또한 Windows 2000에서 "{impersonationLevel=impersonate}" 문은 "impersonate"가 COM에 대해 구성된 기본 가장 수준이기 때문에 생략할 수 있습니다. 그러나 Windows NT 4.0과 같은 이전 플랫폼에서도 동일하게 작동할 수 있도록 이 예제에서는 이것을 그대로 사용합니다.

중지된 자동 서비스 나열

자동 실행되도록 설정했지만 사용자가 수동으로 중지하는 등 어떤 이유로 현재 실행 중이 아닌 서비스만 보려면 아래에서 굵게 표시된 것처럼 스크립트 쿼리 버전에서 한 가지만 변경하면 됩니다.

Set ServiceSet =
GetObject("winmgmts:{impersonationLevel=impersonate}")
.ExecQuery("select * from Win32_Service where State='Stopped' and
StartMode='Auto'")
for each Service in ServiceSet
WScript.Echo Service.Description
next
if ServiceSet.Count = 0 Then WScript.echo "쿼리 기준과 일치하는 서비스가 없습니다."

SQL 데이터베이스의 특정 정보를 요청할 때와 마찬가지로, 부팅 시 자동 실행되도록 구성되었지만 현재 중지되어 있는 서비스의 목록을 얻으려면 쿼리에 WHERE 절을 추가하면 됩니다. 지정한 쿼리는 이미 얻은 결과의 범위를 State 속성에 "Stopped" 값이 있고 StartMode 속성이 "Auto"로 설정된 인스턴스로 좁힙니다.

요구하는 정보 세트의 특성에 따라 쿼리는 아주 단순할 수도 있고 매우 복잡할 수도 있습니다. 기준에 일치하여 반환되는 인스턴스가 없는 경우를 포착하기 위해 스크립트의 끝에 행 하나를 추가한 점에 유의해야 합니다. 이 시나리오에서는 이런 상황이 발생할 가능성이 높습니다. 이 스크립트에 의해 반환되는 인스턴스를 보기 위해 시스템의 인쇄 스풀러를 임시 중지하고 스크립트를 실행할 것을 권장합니다. 인쇄 스풀러를 끄기 전에는 "쿼리 기준과 일치하는 서비스가 없습니다." 메시지가 표시되고, 이후에는 중지된 스풀러 서비스를 나타내는 인스턴스 하나가 결과로 표시됩니다. 이 테스트를 마친 후에는 인쇄 스풀러 서비스를 다시 시작하고 스크립트에 의해 반환되는 인스턴스에서 인쇄 스풀러 서비스가 사라졌는지 확인해야 합니다.

사용 가능한 공간이 20% 미만인 모든 드라이브 파티션 나열

드라이브 공간이 부족한지 확인하려면 Win32_LogicalDisk 클래스의 FreeSpace와 Size 등 두 속성을 검색합니다. 이 두 가지 정보를 이용하면 사용 가능 공간의 백분율을 알 수 있고 한계보다 작은 디스크 파티션을 확인할 수 있습니다.

Set DiskSet =
GetObject("winmgmts:{impersonationLevel=impersonate}")
.ExecQuery("select FreeSpace,Size,Name from Win32_LogicalDisk where
DriveType=3")
for each Disk in DiskSet
If (Disk.FreeSpace/Disk.Size) < 0.20 Then
WScript.Echo + Disk.Name + " 드라이브의 공간이 부족합니다."
End If
Next

이 쿼리에서는 스크립트 작성에 필요한 정확한 속성들이 필요하지만 그것들이 모두 Win32_LogicalDisk 클래스에 들어 있지는 않습니다. WHERE 절에서는 로컬 하드 디스크에 대한 정보를 얻기 위해 해당 드라이브 종류(DriveType=3)로 쿼리를 제한합니다. 이 필터 플로피 드라이브를 사용하지 않으면 CD-ROM 드라이브와 네트워크 공유도 검사에 포함하게 되므로 바람직하지 않습니다. 또한 공간 부족 메시지를 표시할 경우에 사용하기 위해 이름 속성도 검색합니다.

운영 체제 부팅 지연 설정

이 스크립트에서는 부팅 시 사용자가 기본 운영 체제가 아닌 다른 부팅 옵션을 선택할 수 있는 시간을 주기 위해 Win32_ComputerSystem 클래스를 사용하여 부팅 지연 설정을 수정합니다. 이 스크립트의 주요 차이점은 Win32_ComputerSystem 클래스의 속성을 수정한 다음 WMI에 다시 기록하여 운영 체제 설정을 업데이트하는 것입니다.

Set CompSysSet =
GetObject("winmgmts:{impersonationLevel=impersonate}"
.ExecQuery("select * from Win32_ComputerSystem")
for each CompSys in CompSysSet
CompSys.SystemStartupDelay = 20
CompSys.Put_()
next
WScript.Echo "부팅 지연 시간 설정"

이 작업을 완료하기 위해 전과 마찬가지로 쿼리를 사용하여 Win32_ComputerSystem 클래스를 열거합니다. 이 스크립트에서는 각 인스턴스를 순환하면서 임시 변수의 SystemStartupDelay 속성 값을 원하는 값으로 설정합니다. 그러나, 이 클래스의 경우 주어진 컴퓨터에 대한 컴퓨터 시스템 인스턴스가 하나뿐이므로 인스턴스가 항상 하나 밖에 없습니다. 마지막에는 변경된 값을 사용하여 인스턴스를 다시 쓰기 위해 Put_() 메서드를 호출합니다. 한 번의 Put_() 호출로 인스턴스의 여러 속성을 동시에 업데이트할 수 있습니다. WMI에서 지원되는 쓰기 가능한 모든 속성에 동일한 메커니즘을 적용할 수 있습니다.

20초의 값이 속성에 기록됩니다. 스크립트를 실행한 후 그림 2와 같이 제어판의 시스템 애플릿에 있는 고급 탭의 시작 및 복구 옵션에서 이 값을 확인할 수 있습니다.

 

그림 2 시작 및 복구 옵션

응용 프로그램 이벤트 로그 백업

Win32_NTEventLogFile 클래스는 Windows NT 4.0과 Windows 2000의 이벤트 로그를 모델로 합니다. 기본적으로 System, Security, Application 등 세 가지 표준 이벤트 로그가 있습니다. 이 예제에서는 이 로그 중 하나를 백업하는 메서드를 호출합니다. WMI의 메서드는 특정 관리 개체에 적용되는 단순한 함수 호출입니다. 여기서 백업 메서드는 Windows NT 이벤트 로그 개체의 인스턴스에 적용됩니다.

LogFileSet =
GetObject("winmgmts:{impersonationLevel=impersonate,(Backup)}")
.ExecQuery("select * from Win32_NTEventLogFile where
LogfileName='Application')
for each Logfile in LogFileSet
RetVal = LogFile.BackupEventlog("c:\BACKUP.LOG")
if RetVal = 0 then WScript.Echo "로그를 백업했습니다."
next

이 쿼리는 Win32_NTEventLogFile 클래스를 대상으로 실행되고 관심 있는 특정 로그 파일인 "Application"을 필터링한다는 점에서 기본 원칙은 이전과 동일합니다. GetObject() 호출에 "(Backup)" 문이 추가된 점에 유의하십시오. 이벤트 로그 파일을 백업하려면 계정에 "백업" 권한을 부여해야 합니다. NT 보안 그룹인 Administrators 및 Backup Operators 그룹의 구성원에게는 이 권한이 기본적으로 부여됩니다. 그러나, 권한이 부여된 것만으로는 그 권한을 사용할 수 없습니다. 권한이 부여된 백업과 같은 작업을 실행할 때는 사용하기 전에 사용자가 권한을 명시적으로 사용 가능하게 설정해야 합니다. GetObject() 호출에 "(Backup)"을 지정하지 않으면 이 스크립트를 실행할 때 BackupEventlog() 메서드 호출 시 "액세스 거부" 메시지를 받고 작업이 수행되지 않습니다. BackupEventlog() 메서드는 유일한 매개 변수로 백업 파일의 경로 및 이름을 사용합니다.

백업 후 Appication 이벤트 로그에서 항목을 지우려면 아래에 굵게 표시된 것과 같이 스크립트를 간단히 수정하면 됩니다.

LogFileSet =
GetObject("winmgmts:{impersonationLevel=impersonate,(Backup)}")
.ExecQuery("select * from Win32_NTEventLogFile where
LogfileName='Application'")
for each Logfile in LogFileSet
RetVal = LogFile.BackupEventlog("c:\BACKUP.LOG")
if RetVal = 0 then WScript.Echo "로그를 백업했습니다."
RetVal = LogFile.ClearEventlog()
if RetVal = 0 then WScript.Echo "로그를 지웠습니다."
next

업데이트된 예제에서 굵게 표시된 영역은 ClearEventlog() 메서드를 호출하여 로그 파일을 지우고 결과가 성공적이면 메시지를 표시하는 기능을 합니다.

원격 컴퓨터 다시 부팅

WMI에 대한 원격 작업은 로컬에서 수행하는 작업과 거의 같습니다. 이전의 모든 예제는 기본인 로컬 시스템 대신 원격 컴퓨터로 대상을 지정하도록 쉽게 수정할 수 있습니다. WMI를 다루는 데 있어 특정 대상 컴퓨터를 호출하는 것 이외에 차이점이 없습니다. 이렇게 하면 아주 단순한 스크립트를 사용하여 개별적으로 또는 전체 엔터프라이즈에 걸쳐 정보 속성이나 메서드를 액세스할 수 있게 되므로, 이는 결코 작은 변화가 아닙니다. 이제 Win32_OperatingSystem 클래스의 Reboot() 메서드를 사용하여 원격 시스템을 다시 부팅합니다.

Set OpSysSet =
GetObject("winmgmts:{impersonationLevel=impersonate,(RemoteShutdo
wn)}//alexn-pc ").ExecQuery("select * from Win32_OperatingSystem
where Primary=true")
for each OpSys in OpSysSet
OpSys.Reboot()
Next

이 스크립트를 만들기 위해서는 원격 컴퓨터를 쿼리하여 실행 중인 운영 체제의 인스턴스를 알아내야 합니다. 여기서는 Primary 플래그가 TRUE로 설정된 운영 체제를 알아냅니다. 물론 메서드에서 올바른 시스템을 쿼리하도록 하기 위해 컴퓨터 이름 alexn-pc를 지정해야 합니다. 이 경우 대상 컴퓨터를 지정하는 이외에 로컬 컴퓨터에서 정보를 검색하는 방법에는 차이가 없습니다.

여기서도 작업이 권한이 부여된 작업임에 유의해야 합니다. 이 스크립트를 성공적으로 사용하려면 사용자가 원격 컴퓨터의 Administrator 그룹 구성원이어야 합니다. 스크립트가 제대로 작동하려면 원격에서 시스템을 종료할 수 있는 권한이 원격 시스템에서 사용자에게 부여되어야 하고, 권한이 부여된 작업을 시도하기 전에 "(RemoteShutdown)"을 사용하여 권한을 명시적으로 사용 가능하게 설정해야 합니다. 앞에서 설명한 것처럼 모든 사용 권한과 특권은 스크립트를 실행하는 로그인한 사용자를 기초로 합니다. WMI는 수행이 허용된 정보와 동작만 가능하도록 사용자 계정에 현재 정의된 권한을 구체화합니다.

WMI를 통해 메모장 시작

이 예제에서는 Win32_Process 클래스의 WMI 메서드를 통해 새 프로세스를 시작합니다. 여기서는 보여주기 위한 목적으로 비교적 단순한 응용 프로그램인 메모장을 선택했지만 실행 가능한 다른 응용 프로그램을 사용할 수도 있습니다. 이는 비교적 경험이 적은 사용자를 지원하는 담당자에게 매우 유용할 수 있습니다. 예를 들어, 사용자에게 진단 도구 실행을 위한 사용자 인터페이스, 메뉴 등을 제공하기 보다는 지원 담당자가 스크립트를 이용하여 WMI를 통해 원격으로 진단 도구를 호출하는 도구를 사용자 시스템에 표시할 수 있습니다. 이것만으로도 상당히 시간을 절약할 수 있습니다.

set process =
GetObject("winmgmts:{impersonationLevel=impersonate}
!Win32_Process")
result = process.Create ("notepad.exe",null,null,processid)
WScript.Echo "메서드에서 반환된 결과 = " & result
WScript.Echo "새 프로세스의 ID : " & processed

이 예제에는 두 가지 새로운 개념이 있습니다. 새로 개발된 개념 중 첫째는 Win32_Process 클래스를 요청할 때 GetObject() 호출에 COM 모니커 표기를 사용하는 것입니다. 모니커는 다른 COM 개체의 위치를 포함하고 바인딩하기 위한 COM 표준 메커니즘입니다. 이를 통해 디스플레이 이름을 토대로 특정 개체로 되돌아갈 수 있습니다. 둘째 개념은 Win32_Process 클래스의 인스턴스로 되돌아가기 위해 ExecQuery()를 통해 쿼리를 보내는 대신 클래스 개체 자체를 되돌리도록 요청하는 것입니다. 그 이유는 아주 간단하지만 분명하게 드러나지는 않을 수도 있습니다. 새 프로세스를 만드는 것은 실제로 기존 프로세스 인스턴스를 대상으로 하지 않습니다. 현재 실행 중인 프로세스 중 어느 것이 새 프로세스를 시작해야 합니까? 이 문제에는 일관된 답이 없기 때문에 프로세스를 만드는 것이 실제로 Win32_Process 클래스의 새 인스턴스를 만드는 것처럼 보입니다. 따라서 클래스의 인스턴스 대신 클래스 정의 자체를 대상으로 정의되는 정적 메서드 개념이 필요합니다. Win32_Process를 위한 Create() 메서드는 그러한 정적 메서드의 예입니다. 반면에 이전의 모든 메서드 예제는 개별 인스턴스를 대상으로 동작하는 동적 메서드입니다. 우연하게도 Delete() 메서드는 대개 클래스 전체가 아닌 특정 인스턴스에 적용되므로 동적 메서드입니다.

Create() 메서드는 입력 매개 변수를 여러 개 사용하지만 이 예제에서는 시작할 실행 파일 이름인 "notepad.exe"만 제공했습니다. 이 메서드는 작업의 성공 또는 실패를 나타내는 값뿐만 아니라 만들어진 새 프로세스의 ID도 반환합니다. 이 스크립트에서는 메서드를 실행한 후 메서드의 실행 결과와 프로세스 ID 값을 표시하며 메모장 응용 프로그램이 바탕 화면에 나타납니다.

WMI에서 Windows NT 로그 이벤트 수집

지금까지 데이터를 일부 수집하고 몇 가지 메서드를 실행했으므로 이제는 주제를 이벤트로 이동합니다. WMI는 시스템에서 발생하는 다양한 변경 내용이나 상황을 위한 이벤트를 제공할 수 있습니다. 이 예제에서는 Windows NT 또는 Windows 2000 이벤트 로그에 기록되는 모든 새 이벤트를 등록하도록 스크립트를 만듭니다. 새 이벤트가 기록되면 WMI는 이 스크립트와 같은 이벤트 소비자가 받을 수 있는 WMI 이벤트를 생성합니다. 그러나, 이벤트를 받을 소비자가 하나 이상 등록되어 있어야 WMI 이벤트가 전송됩니다. 등록된 소비자가 없으면 WMI는 시스템에서 특정 상황이 발생하는지 감시하느라 리소스를 낭비하지 않습니다.

set events =
GetObject("winmgmts:{impersonationLevel=impersonate}")
.ExecNotificationQuery _
("select * from __instancecreationevent where targetinstance
isa 'Win32_NTLogEvent'")
if err <> 0 then
WScript.Echo Err.Description, Err.Number, Err.Source
end if
'아래의 호출은 무한정 기다립니다 -
필요하면 시간 제한을 지정할 수 있습니다.
WScript.Echo "NT 이벤트를 기다리는 중..."
do
set NTEvent = events.nextevent
if err <> 0 then
WScript.Echo Err.Number, Err.Description, Err.Source
Exit Do
else
WScript.Echo NTEvent.TargetInstance.Message
end if
loop
WScript.Echo "완료"

이 스크립트에서는 발생할 경우 전송할 이벤트의 종류를 정의하는 쿼리를 보내기 위해 ExecNotificationQuery() 메서드를 사용합니다. 이벤트가 로그에 기록되면 효과적으로 Win32_NTLogEvent 클래스의 인스턴스가 생성됩니다. WMI는 인스턴스의 생성, 수정 또는 삭제 시간을 감지할 수 있으며 이 정보는 검색하려는 이벤트의 소스가 됩니다. SQL 쿼리 문은 "만들어지는 인스턴스가 Win32_NTLogEvent 클래스에 속하는 경우 인스턴스를 만드는 모든 이벤트를 전송"하도록 WMI에 알립니다. 다른 클래스에 대한 인스턴스를 만드는 이벤트는 쿼리의 기준과 일치하지 않기 때문에 보고되지 않습니다.

이 스크립트에서는 이벤트가 도착할 때까지 단순히 루프를 반복하다가 수신된 인스턴스의 메시지 속성을 표시합니다.

CPU 사용률이 높은 이벤트 수집

이전 예제에서는 이벤트 로그 공급자가 이벤트를 직접 제공하고 새 이벤트가 로그되면 이벤트 로그 서비스에 의해 다시 호출되는 공급자가 이벤트를 처리합니다. 그러나, 관심 있는 이벤트를 보고하기 위해 모든 서비스에서 이와 같은 메커니즘을 제공하지는 않으며 이 메커니즘을 제공하는 것이 반드시 좋은 것은 아닙니다. WMI에는 일부 장치 정보에 대한 이벤트가 없는 대신 이벤트 지원이 없는 경우에 이벤트를 생성하는 기본 메커니즘이 있습니다. 사실상 속성은 장치 정보이므로 이벤트의 소스가 될 수 있습니다.

이 예제에서는 CPU 사용률을 어떻게 모니터하며, 프로세서 로드가 많을 때 어떻게 이벤트가 발생하여 등록된 소비자에게 전송되는지 보여줍니다. 운영 체제에 이러한 특정 이벤트를 측정하기 위한 내부 이벤트 메커니즘이 없어도 이 예제를 사용할 수 있습니다.

set events =
GetObject("winmgmts:{impersonationLevel=impersonate}")
.ExecNotificationQuery _
("select * from __instancemodificationevent within 5 where
targetinstance isa 'Win32_Processor' and
targetinstance.LoadPercentage > 50")
if err <> 0 then
WScript.Echo Err.Description, Err.Number, Err.Source
end if
'아래의 호출은 무한정 기다립니다 -
필요하면 시간 제한을 지정할 수 있습니다.
WScript.Echo "CPU 로드 이벤트를 기다리는 중..."
WScript.Echo ""
do
set NTEvent = events.nextevent
if err <> 0 then
WScript.Echo Err.Number, Err.Description, Err.Source
Exit Do
else
WScript.Echo NTEvent.TargetInstance.DeviceID WScript.Echo
NTEvent.TargetInstance.LoadPercentage
end if
loop

WScript.Echo "완료"

이 스크립트에서는 이전 Windows NT 이벤트 로그를 수정하여 CPU에 심한 부하가 있는지 확인합니다. 이전 예제와는 달리 이 예제에서는 인스턴스 생성 대신 인스턴스 수정과 관련된 이벤트를 감시합니다. 또한, 모니터 대상 클래스는 Win32_Processor 클래스이며, Win32_Processor 클래스의 구성원인 LoadPercentage 속성이 50보다 큰 값을 가져야 하는 제약 조건이 추가되었습니다. WMI가 LoadPercentage 속성의 값을 모니터하고 그 값이 변경되어 쿼리 기준에 맞으면 이벤트를 생성하기 때문에 값을 모니터할 빈도를 알려주는 매개 변수가 필요합니다. 쿼리에서 WITHIN 절이 이 목적에 사용됩니다. WITHIN 절에서는 WMI가 속성의 값을 검사하고 변경 여부와 쿼리 요구 사항 충족 여부를 확인하기 전에 경과해야 하는 최대 시간 간격을 정의합니다. 이 값은 원하는 이벤트를 얻기 전에 소비자가 기다리게 될 최대 시간으로 생각할 수도 있습니다.

이전의 예제에서와 마찬가지로 쿼리 기준이 충족되면 WMI가 스크립트로 이벤트를 전송하고 스크립트에서는 이벤트에 대한 몇 가지 정보를 인쇄합니다. 여기서는 CPU 이름과 실제 측정된 로드의 백분율이 표시됩니다. 우연하게도 이 스크립트는 단일 CPU 시스템과 다중 CPU 시스템 모두에서 똑같이 잘 작동합니다. 이 스크립트는 Win32_Processor 클래스의 인스턴스에 영향을 주는 인스턴스 수정 사항을 검색하기 때문에 지정한 로드 기준을 초과하는 모든 CPU를 보고합니다. 물론 특정 CPU 로드에만 관심이 있으면 로드 범위를 제한하기 위해 쿼리를 쉽게 변경할 수 있습니다.

WMI를 통해 볼 수 있는 모든 속성에 대해 그것이 운영 체제에서 제공한 장치 정보에 속하든 다른 공급업체가 추가한 장치 정보에 속하는 것이든 관계 없이 동일한 기능성을 적용할 수 있습니다. 이 경우 추가로 수행해야 하는 작업은 없습니다. 이 기능은 제품에 WMI를 사용하면 무료로 제공되는 표준 기능입니다. 또한, 바탕의 API가 동일한 정보를 보다 최적화된 방식으로 공급할 수 있는 내부 이벤트 시스템을 지원하는 경우, 공급자의 작성자는 이벤트 소비자가 차이점을 알 필요가 없도록 쉽고 자연스럽게 WMI 이벤트 모니터링을 무시할 수 있습니다. 따라서 소비자는 작업 방식을 변경하지 않고도 자동으로 최상의 이벤트 메커니즘의 장점을 활용할 수 있습니다. 또한 이벤트를 위해 등록된 이벤트 소비자가 없으면 WMI는 앞서 설명한 방식으로 속성을 모니터하지 않는다는 점을 다시 강조합니다. 스크립트가 끝나는 등, 등록이 제거되면 WMI는 요청된 이벤트를 더 이상 감시하지 않습니다.

결론

WMI는 Windows 플랫폼을 관리하기 가장 쉬운 운영 체제로 만들고 고객의 TCO를 절감하기 위한 Microsoft 전략의 핵심 부분입니다. 산업 표준에 기초하며 DMFT의 승인을 받은 WMI는 로컬에서나 원격으로 일관되고 스크립팅 가능한 방식으로 컴퓨터 시스템을 관리할 수 있게 하는 풍부하고 확장 가능한 개체 모델을 제공합니다. Windows 2000과 함께 제공된 기본 WMI 시스템에는 대부분의 핵심 운영 체제 정보와 서비스가 이미 준비되어 있습니다. Microsoft의 다른 제품이나 다른 공급업체 제품에 대한 장치 정보도 현재 사용 가능하거나 개발 중에 있으므로 WMI는 Windows 기반 시스템을 확장 가능하며 신뢰성이 높고 균일한 방식으로 관리하기 위한 최선의 방법이 되고 있습니다.

이 기사에서는 WMI에서 사용할 수 있는 몇 가지 유용한 기능을 소개했습니다. WMI는 Microsoft Visual Basic, Microsoft Visual C++®와 같은 스크립트 언어를 통해 쉽고 강력하게 액세스할 수 있는 클래스, 속성, 메서드, 이벤트 및 연결의 개체 지향 세트를 제공합니다. 몇 가지 예제 스크립트를 통해 WMI의 강력한 기능을 보여주었지만 이는 극히 일부에 지나지 않습니다. 함께 제공된 장치 정보 차트와 이 예제들을 통해, 시스템을 강력하게 관리할 수 있도록 하기 위해 WMI에서 제공하는 정보를 탐구할 수 있는 기회가 되길 바랍니다. 앞으로 발표될 기사에서는 WMI 공급자 작성, 고급 이벤트 처리, 클라이언트 응용 프로그램 같은 보다 심도 있는 개념을 소개하겠습니다.

WMI 구성 요소를 만들고 사용하는 방법이 수록된 전체 설명서는 MSDN Windows 2000 Platform SDK의 일부로 제공되는 WMI SDK에 있습니다. 또는 http://msdn.microsoft.com/developer/sdk/wmisdk/ 에서 무료로 다운로드할 수도 있습니다. 이 사이트에서 Windows NT 4.0 시스템과 Windows 95/98에 필요한 핵심 WMI 구성 요소도 다운로드할 수 있습니다.