Greg Stemp, Dean Tsaltas, Bob Wells
Microsoft Corporation

Ethan Wilansky
Network Design Group

요약: Scripting Guys의 첫 번째 스크립팅 클리닉 칼럼은 WMI 스크립팅 라이브러리를 사용하여 유용한 Windows 시스템 관리 스크립트 배열을 만드는 방법에 대해 설명합니다.

Microsoft WMI(Windows Management Instrumentation)는 Microsoft의 기밀 사항으로, WMI는 Windows에 대한 Microsoft의 주요 관리 기술입니다. 이것은 어떤 의미입니까? Windows 서버와 워크스테이션을 관리하는 경우 또는 Windows 관리 응용 프로그램을 만들 경우 WMI를 알고 있어야 합니다. 이 기사는 WMI 특히, WMI 스크립팅 라이브러리를 사용하여 Windows 시스템 관리 스크립트 배열을 만드는 방법을 설명하는 시리즈의 첫 번째 기사입니다.

시작하기 전에 스크립팅 클리닉을 진행할 기회를 제공한 Andrew Clinick에게 다시 한 번 감사드립니다. Andrew가 자신의 마지막 칼럼에서 더 많은 정보를 제공할 계획이라고 말했을 때 여러분은 그가 농담하는 것이 아니라는 것을 알 수 있었을 것입니다. 사실은 Andrew가 현재 다른 프로젝트를 진행하고 있기 때문에 자신이 중단한 일을 저희가 다시 진행해주기를 정중하게 요청했습니다. 스크립팅 클리닉에 대해 Andrew가 설정한 난이도가 높은 관계로 처음에는 내키지 않았지만 기꺼이 맡기로 했습니다.

그럼, 저희에 대해 소개하겠습니다. 저희는 Microsoft Windows Server 2003 Resource Kit의 일부로 제공될 새 설명서인 System Administration Scripting Guide를 집필한 Scripting Guys라는 팀입니다.

WMI란?

원래 1998년 Windows NT 4.0 서비스 팩 4의 추가 구성 요소로 릴리스된 WMI는 Windows 2000, Windows XP 및 Windows Server 2003 운영 체제 제품군에 구축된 핵심 관리 기술입니다. DMTF(Distributed Management Task Force)에 의해 발견된 업계 표준을 기반으로 한 WMI는 거의 모든 Windows 리소스를 액세스하고 구성하고 관리하고 모니터링할 수 있는 수단이자 통로입니다.

WMI의 기능을 이해하려면 작년에 그리고 현재까지 Windows 워크스테이션과 서버를 관리하고 모니터링했던 방법을 생각해 보십시오. 디스크, 이벤트 로그, 파일, 폴더, 파일 시스템, 네트워크 구성 요소, 운영 체제 설정, 성능 데이터, 프린터, 프로세스, 레지스트리 설정, 보안, 서비스, 공유, 사용자, 그룹 등과 같은 Windows 리소스를 관리하는 수많은 그래픽 관리 도구를 사용해 봤거나 현재 사용하고 있을 것입니다.

그래픽 관리 도구가 기능적인 관리 솔루션을 제공하긴 했지만 그들의 공통점은 무엇일까요? 한 가지 대답은 WMI 이전에는 모든 Windows 그래픽 관리 도구가 Windows 리소스를 액세스하고 관리하는 데 Win32 API(Application Programming Interface)에 의존했다는 것입니다. 그 이유는 무엇일까요? WMI 이전에는 Win32 API를 통해서만 프로그래밍 방식으로 Windows 리소스에 액세스할 수 있었기 때문입니다. 대부분의 스크립팅 언어에서 Win32 API를 직접 호출할 수 없기 때문에 널리 사용되고 있는 스크립팅 언어를 사용하여 일반 시스템 관리 작업을 자동화하는 쉬운 방법이 없는 이러한 상황이 Windows 시스템 관리자에게 남겨진 것입니다. WMI는 모든 Windows 리소스를 외부 세계에 설명하고 드러내어 일관된 모델과 프레임워크를 제공함으로써 이러한 문제를 변화시켰습니다. 그리고 무엇보다도 시스템 관리자는 WMI 스크립팅 라이브러리를 사용하여 WMI를 통해 게시된 Windows 리소스를 관리할 시스템 관리 스크립트를 만들 수 있습니다.

Windows 스크립트 호스트와 Microsoft Visual Basic Scripting Edition(VBScript) 또는 COM 자동화를 지원하는 모든 스크립트 언어(예: ActiveState Corporation의 ActivePerl)를 사용하여 다음과 같은 기업용 시스템, 응용 프로그램 및 네트워크를 관리하고 자동화하는 스크립트를 작성할 수 있습니다.

• Windows Server 2003, Windows XP Professional 및 Windows 2000 시스템 관리 스크립트를 작성하여 성능 데이터를 검색하고 이벤트 로그, 파일 시스템, 프린터, 프로세스, 레지스트리 설정, 스케줄러, 보안, 서비스, 공유 및 여러 가지 기타 운영 체제 구성 요소와 구성 설정을 관리할 수 있습니다.
• 네트워크 관리 WMI 기반 스크립트를 만들어 DNS, DHCP 및 SNMP 사용 장치와 같은 네트워크 서비스를 관리할 수 있습니다.
• 실시간 상태 모니터링 WMI 이벤트 가입을 사용하여 발생할 때마다 이벤트 로그 항목, 파일 시스템과 레지스트리 수정 및 기타 실시간 운영 체제 변경 사항을 모니터링하고 응답할 스크립트를 작성할 수 있습니다. 개념적으로 WMI 이벤트 가입 및 알림이 WMI에 대해 갖는 의미는 SNMP 트랩이 SNMP 세계에 대해 갖는 의미와 같습니다.
• Windows .NET Enterprise Server 관리 Microsoft Application Center, Operations Manager, Systems Management Server, Internet Information Server, Exchange Server 및 SQL Server를 관리할 스크립트를 작성할 수 있습니다.

WMI 스크립팅 빠른 시작

WMI 스크립팅에 대한 개념을 파악할 수 있도록 하기 위해 원격의 Windows 기반 컴퓨터에 설치된 총 실제 메모리 양을 검색하는 간단한 작업을 살펴보겠습니다. WMI 이전에는 타사의 도구를 추가하지 않고서는 스크립트를 사용하여 이러한 작업을 쉽게 수행할 수 없었습니다. 사실 WMI 이전에 운영 체제 도구에 포함된 도구를 사용하여 컴퓨터에 설치된 메모리의 양을 결정하는 유일한 방법은 시스템 속성 대화 상자를 사용하는 것이었습니다. 현재는 제공되는 WMI가 대상 컴퓨터에 설치되어 사용자가 이 컴퓨터에 대한 관리자 액세스 권한을 갖게 되므로 목록 1에 표시된 스크립트처럼 간단한 WMI 스크립트를 사용하여 원격 Windows 컴퓨터에 설치된 실제 메모리의 양을 검색할 수 있습니다.

목록 1. WMI 및 VBScript를 사용하여 총 실제 메모리 검색

strComputer = "atl-dc-01"

Set wbemServices = GetObject("winmgmts:\\" & strComputer)
Set wbemObjectSet = wbemServices.InstancesOf("Win32_LogicalMemoryConfiguration")

For Each wbemObject In wbemObjectSet
    WScript.Echo "총 실제 메모리(kb): " & wbemObject.TotalPhysicalMemory
Next
 

목록 1의 예제 스크립트를 실행하려면 이 스크립트를 복사하여 원하는 텍스트 편집기에 붙여넣고 strComputer 변수에 할당된 값을 도메인의 유효한 WMI 사용 가능 컴퓨터로 변경하고 .vbs 확장명을 가진 스크립트로 저장한 다음, 그림 1에 나타난 대로 이 스크립트를 실행합니다.

그림 1. GetMemory.vbs 출력

약간의 마술을 부려서 오타만 없다면 콘솔에 에코된 대상 컴퓨터의 실제 메모리 양이 나타납니다.

목록 1에 제공된 것과 동일한 기본 단계를 사용하여 WMI를 통해 게시된 Windows 리소스에서 구성 및 상태 정보를 검색할 수 있다는 것이 아직 명백하게 드러나지 않았으므로 "6줄의 스크립트를 사용하여 정말로 컴퓨터의 메모리 양을 가져올 수 있습니까?"라고 여러분이 묻기 전에 저희도 정중하게 같은 의문을 가져보겠습니다.

원격 컴퓨터에 설치된 모든 서비스 이름, 상태 및 시작 유형을 검색하려 한다고 가정합시다. 목록 2의 예제 스크립트는 목록 1에 사용된 동일한 기본 단계를 사용합니다.

목록 2. WMI 및 VBScript를 사용한 서비스 정보 검색

strComputer = "atl-dc-01"

Set wbemServices = GetObject("winmgmts:\\" & strComputer)
Set wbemObjectSet = wbemServices.InstancesOf("Win32_Service")

For Each wbemObject In wbemObjectSet
    WScript.Echo "표시 이름:  " & wbemObject.DisplayName & vbCrLf & _
                 "   상태:      " & wbemObject.State       & vbCrLf & _
                 "   시작 모드: " & wbemObject.StartMode
Next
 

목록 2를 실행하면 그림 2에 표시된 출력이 생성됩니다.

그림 2. GetServices.vbs 출력

서비스에는 관심이 없지만 Windows 이벤트 로그에서 레코드를 검색해야 한다고 가정합시다. 즉, 목록 1의 스크립트 템플릿을 사용하여 목록 3에 표시된 대로 Windows 이벤트 로그를 쉽게 읽을 수 있습니다. 목록 3을 실행하기 전에 이벤트 로그에 수천 개의 레코드가 포함된 경우 예제 스크립트를 실행하는 데 오랜 시간이 걸릴 수 있다는 점을 주목하십시오.

목록 3. Windows 이벤트 로그 레코드 읽기

strComputer = "atl-dc-01"

Set wbemServices = GetObject("winmgmts:\\" & strComputer)
Set wbemObjectSet = wbemServices.InstancesOf("Win32_NTLogEvent")

For Each wbemObject In wbemObjectSet
    WScript.Echo "로그 파일:        " & wbemObject.LogFile        & vbCrLf & _
                 "레코드 번호:   " & wbemObject.RecordNumber   & vbCrLf & _
                 "종류:            " & wbemObject.Type           & vbCrLf & _
                 "생성된 시간:  " & wbemObject.TimeGenerated  & vbCrLf & _
                 "소스:          " & wbemObject.SourceName     & vbCrLf & _
                 "범주:        " & wbemObject.Category       & vbCrLf & _
                 "범주 문자열: " & wbemObject.CategoryString & vbCrLf & _
                 "이벤트:           " & wbemObject.EventCode      & vbCrLf & _
                 "사용자:            " & wbemObject.User           & vbCrLf & _
                 "컴퓨터:        " & wbemObject.ComputerName   & vbCrLf & _
                 "메시지:         " & wbemObject.Message        & vbCrLf
Next
 

목록 1, 2, 3을 자세히 살펴보면 세 가지 스크립트에 대한 두 가지 중요한 사실을 알 수 있습니다. 첫째는 세 스크립트 모두 동일한 세 가지 단계를 실행한다는 점입니다. 즉, 스크립트가 WMI에 연결되고 WMI 관리 리소스를 검색하고 몇 가지 리소스 속성을 반향합니다. 둘째는 각 스크립트에서 변경된 몇 가지 사항이 대상 리소스를 식별하는 클래스 이름(즉, 각각 Win32_LogicalMemoryConfiguration, Win32_Service 및 Win32_NTLogEvent)과 리소스의 해당 속성이라는 점입니다.

스크립트에 사용된 세 단계는 WMI 관리 리소스에 대한 정보를 검색하는 데 사용된 WMI 스크립트에 공통적입니다. 각 단계를 자세히 살펴보겠습니다.

딘계 1: WMI 서비스에 연결

WMI 스크립트의 첫 번째 단계는 대상 컴퓨터의 Windows 관리 서비스에 연결을 설정하는 것입니다. 로컬 또는 원격 컴퓨터의 WMI에 연결하려면 VBScript의 Getobject 함수를 호출하고 GetObject에 "winmgmts:" 다음에 대상 컴퓨터 이름이 오는 WMI 스크립팅 라이브러리의 모니커 이름을 전달하면 됩니다.

이러한 방식으로 WMI에 연결하면 목록 1, 2, 3의 wbemServices 변수를 사용하여 참조하는 SWbemServices 개체에 대한 참조를 반환합니다. SWbemServices는 WMI 스크립팅 라이브러리에 정의된 수많은 개체 중 하나입니다. WMI 스크립팅 라이브러리는 WMI 인프라에 액세스하는 데 사용되는 일반적인 용도의 개체 스크립트 집합을 제공합니다. SWbemServices 개체에 대한 참조가 있으면 제공된 SWbemServices 메서드 중 하나를 호출할 수 있습니다. InstancesOf가 그러한 메서드 중 하나입니다.

단계 2: WMI 관리 리소스의 인스턴스 검색

두 번째 단계는 주로 실행할 작업에 따라 다릅니다. WMI 관리 리소스에 대한 정보를 검색하는 경우 이 단계는 SWbemServices 개체의 InstancesOf 메서드를 호출하는 것만큼 간단합니다. 메서드 이름이 나타내듯이 InstancesOf는 리소스의 클래스 이름으로 식별되는 관리 리소스의 모든 인스턴스를 반환합니다. InstancesOf는 wbemObjectSet 변수를 사용하여 목록 1, 2, 3에서 참조하는 SWbemObjectSet 컬렉션 형식으로 요청한 리소스를 반환합니다. SWbemObjectSet은 WMI 스크립팅 라이브러리에 정의된 또 다른 스크립팅 개체입니다.

단계 3: WMI 관리 리소스 속성 표시

마지막이자 최종 단계는 SWbemObjectSet 컬렉션의 컨텐트를 열거하는 것입니다. SWbemObjectSet의 각 항목은 요청한 리소스의 단일 인스턴스를 나타내는 SWbemObject(WMI 스크립팅 라이브러리의 다른 개체)입니다. SWbemObject를 사용하여 관리 리소스의 클래스 정의에 정의된 메서드와 속성에 액세스할 수 있습니다.

그렇다면, WMI에서 정보를 검색하는 스크립팅 단계가 동일할 경우 Win32_LogicalMemoryConfiguration, Win32_Service 및 Win32_NTLogEvent 클래스는 어떻습니까? 또한, 이러한 클래스는 어디에서 온 것이고, 사용 가능한 다른 클래스는 어떤 것이 있으며, 그러한 클래스는 어떻게 사용합니까? 이러한 질문에 대한 대답은 WMI 아키텍처를 구성하는 구성 요소에 있습니다. 한 번 살펴봅시다.

WMI 아키텍처

WMI 아키텍처는 그림 3에 나타난 대로 세 가지 주요 계층으로 구성됩니다.

• 관리 리소스
• WMI 인프라
• 소비자

그림 3. WMI 인프라

리소스가 상주한 가장 낮은 계층에서 시작하겠습니다.

관리 리소스

관리 리소스는 WMI를 사용하여 게시되고 관리할 수 있는 논리적 또는 물리적 구성 요소입니다. WMI를 사용하여 관리할 수 있는 Windows 리소스에는 컴퓨터 시스템, 디스크, 주변 장치, 이벤트 로그, 파일, 폴더, 파일 시스템, 네트워킹 구성 요소, 운영 체제 하위 시스템, 성능 카운터, 프린터, 프로세스, 레지스트리 설정, 보안, 서비스, 공유, SAM 사용자 및 그룹, Active Directory, Windows Installer, WDM(Windows Driver Model) 장치 드라이버 및 SNMP MIB(Management Information Base) 데이터가 있습니다. WMI 관리 리소스는 공급자를 통해 WMI와 통신합니다. WMI 관리 리소스와 상호 작용할 스크립트를 작성할 때 실행 스크립트의 관리 리소스에 대한 가상 표현을 참조하는 데 사용되는 "인스턴스"라는 용어가 자주 나타납니다.

WMI 인프라

중간 계층은 WMI 인프라입니다. WMI는 CIM 개체 관리자(Common Information Model Object Manager), CIM(Common Information Model) 리포지토리 및 공급자의 세 가지 주요 구성 요소로 구성됩니다. 세 가지 WMI 구성 요소는 구성 및 관리 데이터를 정의하고 게시하고 액세스하고 검색하는 인프라를 제공합니다. 작지만 스크립팅에 절대적으로 필요한 네 번째 구성 요소는 WMI 스크립팅 라이브러리입니다.

WMI 공급자

WMI 공급자는 WMI와 관리 리소스 간의 중개자 역할을 합니다. 공급자는 소비자 응용 프로그램 및 스크립트 대신 WMI 관리 리소스에서 정보를 요청하고 WMI 관리 리소스에 설명을 보냅니다. 예를 들어, 목록 1과 2는 기본 제공 Win32 공급자를 사용하여 메모리와 서비스 관련 정보를 검색합니다. 목록 3은 기본 제공 이벤트 로그 공급자를 사용하여 Windows 이벤트 로그에서 레코드를 검색합니다.

공급자는 WMI의 표준 기반 단일 액세스 모델을 기준으로 한 WMI 인프라에 관리 리소스를 제공하여 관리 리소스에 고유한 구현 세부 정보를 숨깁니다. WMI 공급자는 관리 리소스 기본 API를 사용하여 각 관리 리소스와 통신하고 WMI 프로그래밍 인터페이스를 사용하여 CIMOM과 통신합니다. 예를 들면, 기본 제공 이벤트 로그 공급자는 Win32 이벤트 로그 API를 호출하여 이벤트 로그에 액세스합니다.

소프트웨어 개발자는 추가 공급자를 개발하고 통합하여 WMI의 확장 가능한 아키텍처를 기준으로 해당 제품에 고유한 관리 기능을 게시할 수 있습니다. Exchange 커넥터 상태를 모니터링하는 Exchange Server 2000 공급자가 그러한 예입니다. 마찬가지로, Application Center, Operations Manager, Systems Management Server, Internet Information Server 및 SQL Server에 모두 WMI 공급자가 포함되어 있습니다.

일반적으로 공급자는 %SystemRoot%\system32\wbem 디렉터리에 있는 DLL(동적 연결 라이브러리)로 구현됩니다. WMI에는 Windows 2000, Windows XP 및 Windows Server 2003 운영 체제 제품군을 위한 여러 가지 기본 제공 공급자가 포함되어 있습니다. 기본 제공 공급자는 표준 공급자라고도 하며, Win32 하위 시스템, 이벤트 로그, 성능 카운터 및 레지스트리와 같은 잘 알려진 운영 체제 리소스의 데이터 및 관리 기능을 제공합니다. 표 1은 Windows 2000, Windows XP 및 Windows .NET Server 운영 체제 제품군에 포함된 여러 가지 표준 WMI 공급자를 나열합니다.

표 1. 표준 WMI 공급자의 일부 목록

Windows XP 및 Windows Server 2003에는 여러 가지 추가 표준 공급자가 포함되어 있습니다. 표준 공급자의 전체 목록에 대해서는 WMI SDK(Software Developers Kit) 설명서의 WMI Provider 를 참조하십시오.

CIMOM

CIMOM(see-mom으로 발음함)은 소비자와 공급자 간의 상호 작용을 처리합니다. 이 용어는 웹 기반 엔터프라이즈 관리 초기 작업과 Distributed Management Task Force 에서 유지 관리되는 CIM(Common Information Model)에서 가져온 것입니다.

CIMOM을 WMI 정보 중개자로 생각할 수 있습니다. 모든 WMI 요청 및 데이터는 CIMOM으로 전달됩니다. WMI(Windows Management Instrumentation) 서비스 winmgmt.exe는 Windows XP 및 Windows Server 2003 운영 체제 제품군에 CIMOM 역할을 제공하며, 일반 서비스 호스트 프로세스인 svchost.exe 제어를 통해 실행됩니다.

참고   Windows 2000 또는 Windows NT 4.0 서비스 팩 4를 실행하는 컴퓨터에서 WMI 서비스는 별도의 서비스 프로세스로 실행됩니다. Windows ME(Millennium Edition), Windows 98 또는 Windows 95 OSR 2.5를 실행하는 컴퓨터에서 WMI는 표준 실행 프로세스로 실행됩니다.

소비자가 WMI에 액세스하여 일반 인터페이스를 제공하는 것 외에 CIMOM은 다음과 같은 핵심 서비스를 WMI 인프라에 제공합니다.

• 공급자 등록 WMI 공급자는 CIMOM을 사용하여 위치 및 기능 정보를 등록합니다. 이 정보는 CIM 리포지토리에 저장됩니다.
• 요청 라우팅 CIMOM은 공급자 등록 정보를 사용하여 소비자 요청을 해당 공급자에게 라우팅합니다.
• 원격 액세스 소비자는 원격 시스템의 CIMOM에 연결하여 원격 WMI 사용 가능 시스템에 액세스합니다. 연결이 설정되면 소비자는 로컬로 실행할 수 있는 동일한 작업을 실행할 수 있습니다.
• 보안 CIMOM은 로컬 컴퓨터나 원격 컴퓨터에서 사용자의 WMI 연결을 허용하기 전에 각 사용자의 액세스 토큰을 확인하여 WMI 관리 리소스에 대한 액세스를 제어합니다. WMI는 운영 제체에서 제공하는 보안을 무시하거나 방해하지 않습니다.
• 쿼리 처리 소비자가 WQL(WMI Query Language)을 사용하여 WMI 관리 리소스에 대한 쿼리를 제공할 수 있게 합니다. 예를 들면, 지난 24시간 동안 발생한 특정 이벤트 ID에 일치하는 모든 이벤트에 대해 이벤트 로그를 쿼리할 수 있습니다. CIMOM은 공급자가 기본적으로 쿼리 작업을 지원하지 않는 경우 쿼리에 대한 평가를 실행할 수 있습니다.
• 이벤트 처리 소비자가 WMI 관리 리소스에 대한 변경 사항을 나타내는 이벤트에 가입할 수 있도록 합니다. 예를 들면, 논리 디스크 드라이브의 공간이 허용 가능한 임계값 이하로 떨어지는 시기를 나타내는 이벤트에 가입할 수 있습니다. CIMOM은 사용자가 지정한 간격으로 관리 리소스를 폴링하고 가입이 만족스러우면 이벤트 알림을 생성합니다.

관리 응용 프로그램, 관리 도구 및 스크립트는 CIMOM으로 호출되어 데이터를 마이닝하고 이벤트에 가입하거나 기타 관리 관련 작업을 실행합니다. CIMOM은 CIM에서 소비자의 요청을 서비스하는 데 필요한 공급자와 클래스 정보를 얻습니다. CIMOM은 CIM에서 얻은 정보를 사용하여 소비자의 요청을 해당 공급자에게 전달합니다.

CIM 리포지토리

WMI는 다른 소스의 구성 및 관리 정보를 고유하게 스키마로 나타낼 수 있다는 개념을 기반으로 합니다. CIM은 스키마이며, 관리 환경을 모델링하고 WMI에서 제공한 모든 데이터를 정의한 개체 리포지토리 또는 클래스 저장소라고도 합니다. 스키마는 DMTF CIM(Common Information Model) Standards 를 기반으로 합니다.

Active Directory 스키마가 클래스라는 개념 위에 구축된 것처럼 CIM은 클래스로 구성됩니다. 클래스는 WMI 관리 가능 리소스에 대한 청사진입니다. 그러나 디렉터리에 만들어지고 저장된 개체를 나타내는 Active Directory 클래스와 달리, CIM 클래스는 일반적으로 동적 리소스를 나타냅니다. 즉, 리소스 인스턴스가 CIM에 저장되지 않지만 소비자 요청을 기반으로 하여 공급자가 동적으로 리소스 인스턴스를 검색합니다. 그 이유는 간단합니다. 대부분의 WMI 관리 리소스의 운영 상태는 자주 바뀌므로 읽기 요청 시 최신 정보가 검색되도록 합니다.

참고   리포지토리라는 용어는 CIM 컨텍스트에서 오해를 일으킬 수도 있습니다. CIM은 리포지토리이고 정적 데이터를 저장할 수 있지만 주 역할은 관리 리소스에 대한 청사진을 저장하는 것입니다.

Active Directory 클래스와 마찬가지로 CIM 클래스도 하위 클래스가 상위 클래스에서 상속되는 계층 구조로 구성됩니다. DMTF는 Microsoft의 시스템 및 응용 프로그램 소프트웨어 개발자가 시스템 또는 응용 프로그램 특정 확장 클래스를 파생시키고 만드는 것처럼 그러한 개발자로부터 핵심 및 일반 기준 클래스 집합을 유지 관리합니다.

클래스는 특정 관리 영역을 나타내는 논리적 클래스 그룹인 "네임스페이스"에 그룹화됩니다. 예를 들면, root\cimv2 네임스페이스에 일반적으로 컴퓨터 및 운영 체제와 관련된 리소스를 나타내는 대부분의 클래스가 들어 있습니다. 이전 스크립트에 사용된 클래스(Win32_LogicalMemoryConfiguration, Win32_Service 및 Win32_NTLogEvent)는 root\cimv2 네임스페이스에 있으며 CIM에 300개의 클래스가 정의되어 있습니다.

CIM 클래스는 속성과 메서드로 구성되어 있습니다. 속성은 WMI 관리 리소스의 구성 및 상태를 설명하고, 메서드는 WMI 관리 리소스에 작업을 실행하는 실행 함수입니다.

참고   CIM 클래스에 정의된 메서드 및 속성과 WMI 스크립팅 라이브러리의 자동화 개체에서 제공하는 메서드 및 속성을 혼동하지 마십시오.

CIM은 %SystemRoot%\system32\wbem\Repository\FS\ 디렉터리에 상주하며 다음 네 개의 파일로 구성되어 있습니다.

• index.btr. 이진 트리(b 트리) 인덱스 파일입니다.
• index.map. 트랜잭션 제어 파일입니다.
• objects.data. 관리 리소스 정의가 저장된 CIM 리포지토리입니다.
• objects.map. 트랜잭션 제어 파일입니다.

참고   Microsoft Windows 2000 및 Windows NT 4.0 서비스 팩 4에서 CIM은 %SystemRoot%\system32\wbem\Respository\cim.rep에 저장됩니다. Windows ME(Millennium Edition), Windows 98 및 Windows 95 OSR 2.5 운영 체제에서 CIM은 %windir%\system\wbem\Respository\cim.reprep에 저장됩니다.

CIM은 개체 지향 디자인 원칙을 기반으로 하지만 WMI 사용 및 WMI 기반 스크립트 작성을 위해 정보 모델링 또는 스키마 디자인 전문가가 될 필요는 없습니다. 중요한 것은 CIM의 기본 구조와 구성 및 해당 컨텐트 탐색 및 해석 방법을 이해하는 것입니다.

WMI 스크립팅 라이브러리

WMI 스크립팅 라이브러리는 VBScript, Jscript 및 ActiveState의 ActivePerl과 같은 스크립팅 언어에서 WMI 인프라에 액세스하여 자동화 개체 집합을 제공합니다.

WMI 스크립팅 라이브러리의 자동화 개체는 WMI 인프라에 일관된 스크립팅 모델을 제공합니다. 앞에서 설명한 대로, WMI 스크립팅 라이브러리를 사용하여 한 가지 관리 리소스 종류를 검색하는 방법을 이해하면 다른 WMI 관리 리소스를 검색하는 단계를 쉽게 사용할 수 있습니다. 예를 들면, 앞에서 설명한 세 가지 스크립트 중 하나를 사용하여 원격 컴퓨터에서 실행하는 프로세스(Win32_Process)에 대한 정보, 프로세서(Win32_Processor) 정보, 운영 체제(Win32_OperatingSystem) 정보 또는 WMI에서 제공한 수백 가지 관리 리소스 중 하나를 검색하는 스크립트를 쉽게 수정할 수 있습니다.

WMI 스크립팅 라이브러리는 %SystemRoot%\system32\wbem 디렉터리에 있는 wbemdisp.dll이라고 하는 단일 DLL로 구현됩니다. WMI 스크립팅 라이브러리에는 또한 wbemdisp.tlb라고 하는 형식 라이브러리가 있습니다. WMI 스크립팅 형식 라이브러리를 사용하여 .wsf 확장명을 가진 WSH 스크립트인 XML 기반 Windows 스크립트 파일에서 WMI 상수를 참조할 수 있습니다.

WMI 소비자

소비자는 최상위 계층입니다. 소비자는 WMI 인프라를 통해 사용할 수 있는 관리 정보에 액세스하고 제어하는 스크립트, 엔터프라이즈 관리 응용 프로그램, 웹 기반 응용 프로그램 또는 기타 관리 도구입니다.

참고   여러 관리 응용 프로그램은 WMI 소비자와 WMI 공급자의 이중 역할을 수행합니다. Application Center, Operations Manager 및 Systems Management Server와 같은 여러 가지 Microsoft 관리 제품이 이에 해당합니다.

CIM 탐색

수많은 자료를 다루어 왔지만 아직까지 언급되지 않은 한 가지 주요 사항이 있습니다. 그것은 WMI를 통해 제공할 리소스를 결정하는 방법입니다. 다행히 여러 가지 도구를 사용하여 CIM 스키마를 찾아보고 WMI 관리 리소스에 대한 클래스 정의를 검사할 수 있습니다.

• WMI 컨트롤 WMI 컨트롤(wmimgmt.msc)은 로컬 또는 원격 컴퓨터에서 WMI 설정을 구성할 수 있게 해주는 MMC(Microsoft Management Console) 스냅인입니다. WMI 컨트롤을 사용하여 CIM을 찾을 수 없지만 이 도구의 보안 탭을 사용하여 CIM 네임스페이스를 로컬 또는 원격 컴퓨터에서 사용할 수 있는지 여부를 결정할 수 있습니다. WMI 컨트롤 사용에 대한 자세한 내용은 Windows 2000 도움말 또는 Windows XP 도움말의 WMI 컨트롤 개요 및 지원 센터를 참조하십시오.
• WMI 테스터 WMI 테스터(wbemtest.exe)는 WMI 인프라와 상호 작용을 하기 위한 일반적인 용도의 그래픽 도구입니다. WMI 테스터를 사용하여 CIM 스키마를 찾고 관리 리소스 클래스 정의를 검사할 수 있습니다. 또한 WMI 테스터를 사용하여 관리 리소스 인스턴스 검색 및 쿼리 실행과 같이 WMI 기반 스크립트가 실행하는 동일한 작업을 실행할 수 있습니다. WMI 테스터는 WMI를 사용하는 모든 컴퓨터에 기본으로 설치되는 WMI의 일부이므로 wbemtest.exe는 뛰어난 WMI 학습 및 문제 해결 도구입니다. WMI 테스터 사용에 대한 자세한 내용은 Windows XP 도움말의 WMI 테스터 개요 및 지원 센터를 참조하십시오.
• WMI 명령줄 Windows XP의 일부로 릴리스된 WMI 명령줄 도구(wmic.exe)는 WMI 인프라에 명령줄 인터페이스를 제공합니다. wmic.exe를 사용하여 명령줄에서 CIM 찾아보기 및 CIM 클래스 정의 검사와 같은 일반 WMI 작업을 실행할 수 있습니다. WMI 명령줄 도구 사용에 대한 자세한 내용은 Windows XP 도움말의 WMIC(WMI 명령줄) 도구 사용 및 지원 센터를 참조하십시오.
• CIM 스튜디오 CIM 스튜디오는 WMI SDK의 일부로, WMI 인프라와 상호 작용할 웹 기반 인터페이스를 제공합니다. WMI 테스터처럼 CIM 스튜디오를 사용하여 CIM 스키마를 찾아보고 클래스 정의를 보며 관리 리소스의 인턴스를 검색할 수 있습니다. CIM 스튜디오의 고급 사용자 인터페이스를 통해 클래스 관계 및 연결을 쉽게 볼 수 있고 CIM 스튜디오는 WMI 테스터 도구에서 사용할 수 없는 두 가지 기능인 기본 검색 기능을 제공합니다. CIM 스튜디오를 사용하려면 WMI SDK를 다운로드하여 설치해야 합니다. WMI(Windows Management Instrumentation) SDK 에서 WMI SDK를 다운로드할 수 있습니다.
• EnumClasses.vbs, EnumInstances.vbs 및 EnumNamespaces.vbs Windows 2000 Server Resource Kit에는 WMI의 기능을 사용하는 수많은 스크립트가 포함되어 있습니다. 여기에 나열된 세 가지 스크립트는 CIM 스키마를 찾고 클래스 정의를 보고 관리 리소스의 인스턴스를 검색하는 데 사용할 수 있는 일반적인 용도의 스크립트입니다.

다음과 같은 몇 가지 추가 리소스를 확인해야 합니다.

• WMI SDK 설명서 WMI SDK에는 표준 WMI 공급자가 제공한 포괄적인 클래스 목록이 들어 있습니다. MSDN 온라인 라이브러리에서 WMI SDK documentation 에 액세스할 수 있습니다.
• TechNet Script Center TechNet Script Center 에는 다음 System Administration Scripting Guide의 수백 가지 WMI 기반 샘플 스크립트가 들어 있습니다.

WMI 테스터(wbemtest.exe) 연습

CIM 찾아보기 및 탐색에 사용할 수 있는 도구에 대해 알고 있으므로 WMI 테스터(wbemtest.exe)를 사용하여 Win32_Process 클래스 정의를 검사하고 목록 2를 수정하여 현재 컴퓨터에서 실행하는 프로세스에서 여러 가지 속성을 검색해 보겠습니다. 최상의 결과를 얻으려면 이 연습에 들어가기 전에 관리자 권한으로 로그온하십시오.

1. 명령 프롬프트를 열고 C:\>wbemtest.exe를 입력한 다음 Enter 키를 눌러 WMI 테스터 도구를 시작합니다. 기본 WMI 테스터 창에서 대부분의 단추가 비활성화되어 있는지 확인하십시오. 단추가 비활성화되어 있으면 현재 WMI에 연결되어 있는 것이 아닙니다.
2. 연결을 클릭하여 로컬 또는 원격 컴퓨터의 WMI 서비스에 연결합니다. root\default가 기본값으로 제공된 네임스페이스 텍스트 항목 필드를 제공하는 연결 대화 상자가 표시됩니다. 네임스페이스 필드 값을 root\cimv2로 변경하고 연결 대화 상자의 연결 단추를 클릭하여 기본 WMI 테스터 창으로 돌아갑니다.
3. 기본 창의 왼쪽 상단에 있는 네임스페이스 식별자는 root\cimv2로 표시됩니다. 이제 모든 단추가 활성화되어 있습니다. 즉, 현재 자격 증명으로 로컬 호스트에서 WMI에 성공적으로 연결된 것입니다. 클래스 열거를 클릭하여 슈퍼클래스 정보 대화 상자를 엽니다.
4. 슈퍼클래스 정보 대화 상자에서 슈퍼클래스 이름 입력 필드는 비워두고 모든 클래스 옵션을 클릭한 다음 확인을 클릭하여 root\cimv2 네임스페이스에 정의된 모든 CIM 클래스를 열거합니다.

   현재, 수백 개의 클래스 정의를 나열한 쿼리 결과 대화 상자가 표시됩니다. 클래스 수는 주로 현재 실행 중인 Windows 버전에 따라 다릅니다. 예를 들어, Windows 2000을 사용 중이면 600개의 클래스 정의가 나타납니다. Windows XP를 실행 중이면 대략 900개가 나타납니다.

   쿼리 결과 대화 상자 위쪽에 나열된 클래스는 앞에 두 개의 밑줄이 표시됩니다. 이러한 클래스는 시스템 클래스입니다. 시스템 클래스는 공급자 등록, 네임스페이스 보안 및 이벤트 알림과 같은 내부 WMI 구성 및 작업을 지원하는 미리 정의된 CIM 클래스입니다. 현재는 CIM_으로 시작하는 클래스가 나타날 때까지 시스템 클래스를 무시하고 쿼리 결과 대화 상자 아래로 스크롤합니다.

   CIM_으로 시작하는 클래스는 DMTF에서 유지 관리하는 핵심 및 공통적인 기본 클래스입니다. Win32_로 시작하는 클래스가 나타날 때까지 아래로 스크롤합니다.

   Win32_로 시작하는 클래스는 Windows 특정 관리 리소스를 나타내는 Microsoft 확장 클래스입니다. root\cimv2 네임스페이스를 처음 검사하는 경우 root\cimv2 네임스페이스에서 포괄적인 클래스 집합, 특히 Win32_prefix가 있는 클래스 집합에 대해 잘 알고 싶을 것입니다.

5. Win32_Process 클래스가 나타날 때까지 쿼리 결과 대화 상자를 아래로 스크롤하고 클래스 이름을 두 번 클릭하여 Win32_Process에 대한 개체 편집기 대화 상자를 엽니다.
6. 개체 편집기 대화 상자에 선택한 클래스에 대한 정의 및 구현 정보(속성 및 메서드)가 나타납니다. 클래스 정의는 WMI 관리 가능 리소스의 청사진이라고 앞에서 설명한 내용을 상기하십시오.

   시스템 속성 숨기기 확인란을 선택하여 시스템 속성을 숨깁니다. 나머지 Win32_Process 속성은 로컬 또는 원격 컴퓨터에서 실행하는 프로세스에서 검색할 수 있는 정보를 나타냅니다.

   WMI 스크립팅 연습을 완료하려면 Name, Handle 및 ProcessID 속성을 검색해 보십시오. 앞에서 템플릿으로 나열된 세 개 목록 중 하나를 사용하여 단계 7을 실행하기 전에 스크립트를 실행해 보십시오.

   참고   로컬 컴퓨터에서 스크립트를 실행하려면 strComputer 변수 값을 "."(인용 부호 내의 한 점)로 설정합니다.

7. 새로 만든 GetProcesses.vbs 스크립트를 실행한 후에 WMI 테스터를 사용하여 스크립트 결과를 확인할 수 있습니다. Win32_Process 개체 편집기 대화 상자에서 인스턴스를 두 번 클릭합니다. 쿼리 결과 대화 상자의 결과는 사용하는 컴퓨터에서 실행 중인 프로세스의 인스턴스를 나열한 것입니다. 특정 프로세스 인스턴스를 두 번 클릭하여 해당 인스턴스에 대한 세부 정보를 확인합니다.

결론

WMI 스크립팅의 외관만 살펴 보았습니다. 솔직히 말하자면 이것은 의도적인 것이었습니다. WMI는 트리의 포리스트를 놓치기 쉬운 여러 가지 스크립팅 기능을 제공합니다. 그렇지만 걱정하지 마십시오. 이 시리즈를 진행하면서 모든 차이를 알게 되었습니다. 이 시점에서 중요한 것은 WMI는 Windows의 가장 중요한 관리 가능한 단일 기술이며 WMI 기반 스크립트를 작성하는 데 개발자나 스크립팅 전문가일 필요는 없다는 점입니다. 새로 만든 스크립트를 계속 수정하여 추가 프로세스 속성이나 다른 관리 리소스를 검색하십시오. 다음 달에 만날 때 여러분은 사용자에 맞게 설정된 시스템 관리 스크립트에 대한 전문가가 되어 있을 것입니다. 비결을 알려주십시오.

목록 4. WMI 테스터 연습에 대한 응답

strComputer = "."   ' 점(.)은 WMI에서 로컬 컴퓨터와 같습니다.

Set wbemServices = GetObject("winmgmts:\\" & strComputer)
Set wbemObjectSet = wbemServices.InstancesOf("Win32_Process")

For Each wbemObject In wbemObjectSet
    WScript.Echo "이름:          " & wbemObject.Name      & vbCrLf & _
                 "   핸들:     " & wbemObject.Handle    & vbCrLf & _
                 "   프로세스 ID: " & wbemObject.ProcessID
Next
 

스크립팅 클리닉

Greg Stemp는 오랫동안 전국 최고의 스크립팅 대가 중 한 사람으로, 또한 세계적인 풋볼 코치로 널리 인정받아 왔습니다. 그런데 어떻게 풋볼 코치가 이런 일을 하게 되었냐구요? 그는 "해고"되었습니다. Greg Stemp는 ... 이제 그렇게 말할 수 조차 없군요. 좋습니다. Greg Stemp는 Microsoft에서 "System Administration Scripting Guide"의 수석 집필진입니다.

Bob Wells는 관심을 갖고 있는 사람이면 누구에게나 스크립팅의 가치를 역설합니다. Bob이 키우는 두 마리 닥스훈트도 보통 사람보다 스크립팅에 대해 더 많이 알고 있다는 소문이 있습니다. 여가 시간에 Bob은 System Administration Scripting Guide에 기고합니다.

Ethan Wilansky는 많은 시간을 저술 및 컨설팅 활동에 보냅니다. 그리고 스크립팅, 요가, 원예 및 가정일에 열심입니다. 현재는 쓰레기를 버리고 설겆이를 하는 스크립트를 만드는 일에 전념하고 있습니다.

Greg Stemp, Dean Tsaltas, Bob Wells
Microsoft Corporation

Ethan Wilansky
Network Design Group

요약: 스크립팅 개발자들은 계속해서 WMI 스크립트 작성에 관해서 논의를 하고 있으며, 이번에는 WMI 스크립팅의 전체 기능에 대한 이해를 돕기 위해 CIM 리포지토리 및 CIM 클래스에 대해 주로 설명합니다(39페이지/인쇄 페이지 기준).

집을 지으려 한다면 건축 도면을 읽고 해석하는 방법을 알아야 하고 전자 장치를 만들려 한다면 기계 설계도를 읽고 해석하는 방법을 알아야 하듯이, WMI 스크립트를 작성하려 한다면 CIM 리포지토리 관리를 위한 WMI 청사진의 해석 방법을 알아야 합니다. WMI SDK에서 WMI 리포지토리라고도 하는 CIM 리포지토리는 WMI 관리 리소스를 모델링하는 클래스 정의를 저장하는 WMI 스키마입니다.

CIM 및 CIM 클래스의 중요성을 강조하려면 WMI 스크립팅 입문: 1부과 아래의 목록 1 및 목록 2의 네 가지 스크립트를 살펴보십시오. 목록 1은 1부의 약간 강화된 서비스 스크립트 버전이며, 목록 2는 Win32_OperatingSystem 클래스를 사용하는 동일한 스크립트의 변형입니다.

참고   목록 1과 2가 혼동스럽다면 이 시리즈의 1부를 읽어 보십시오(상황이 허락한다면 재차 읽어보십시오).

목록 1. WMI 및 VBScript를 사용한 서비스 정보 검색

strComputer = "  . "   ' 점(.)은 WMI에서 로컬 컴퓨터와 같습니다.

Set objWMIService = GetObject("winmgmts:\\" & strComputer)
Set colServices = objWMIService.InstancesOf("Win32_Service")

For Each objService In colServices
    WScript.Echo "이름:           " & objService.Name        & vbCrLf & _
                 "디스플레이 이름:   " & objService.DisplayName & vbCrLf & _
                 "   설명: " & objService.Description & vbCrLf & _
                 "   경로 이름:   " & objService.PathName    & vbCrLf & _
                 "   시작 모드:  " & objService.StartMode   & vbCrLf & _
                 "   상태:       " & objService.State       & vbCrLf
Next 

목록 2. WMI 및 VBScript를 사용한 운영 체제 정보 검색

strComputer = "."   

Set objWMIService = GetObject("winmgmts:\\" & strComputer)
Set colOperatingSystems = objWMIService.InstancesOf("Win32_OperatingSystem")

For Each objOperatingSystem In colOperatingSystems
    Wscript.Echo "이름:            " & objOperatingSystem.Name   & vbCrLf & _
        "캡션:         " & objOperatingSystem.Caption         & vbCrLf & _
        "CurrentTimeZone: " & objOperatingSystem.CurrentTimeZone & vbCrLf & _
        "LastBootUpTime:  " & objOperatingSystem.LastBootUpTime  & vbCrLf & _
        "LocalDateTime:   " & objOperatingSystem.LocalDateTime   & vbCrLf & _
        "로케일:          " & objOperatingSystem.Locale          & vbCrLf & _
        "제조업체:    " & objOperatingSystem.Manufacturer    & vbCrLf & _
        "OSType:          " & objOperatingSystem.   OSType         & vbCrLf & _
        "버전:         " & objOperatingSystem.Version         & vbCrLf & _
        "서비스 팩:    " & objOperatingSystem.ServicePackMajorVersion  & _
                "."   & objOperatingSystem.ServicePackMinorVersion & vbCrLf & _
        "Windows 디렉터리: " & objOperatingSystem.WindowsDirectory
Next 
 

이 시리즈의 1부와 본 기사의 목록 1 및 2의 각 스크립트에서 눈에 띄는 유일한 특징은 WMI 관리 리소스를 구별하는 클래스 이름과 각 클래스 속성의 하위 집합입니다. 동일한 스크립트 템플릿을 사용하여 총 실제 메모리, 서비스, 이벤트 로그 레코드, 프로세스, 운영 체제 정보를 검색한다는 것은 WMI 스크립팅에서 CIM 클래스의 역할이 얼마나 중요한지를 보여줍니다. 스크립트를 작성하여 한 가지 유형의 WMI 관리 리소스를 관리하는 방법을 알게 되면 다른 관리 리소스에 대해서도 동일한 기본 기술을 사용할 수 있습니다.

물론 관리 리소스의 클래스 이름과 클래스의 해당 속성을 아는 것은 일부의 지식일 뿐입니다. WMI 스크립팅의 전체 기능에 대해 알기 전에 먼저 CIM 리포지토리 및 CIM 클래스의 구조에 대해서 어느 정도 지식이 있어야 합니다. 그 이유는 무엇일까요? 그 중요 이유는 다음과 같습니다.

1. CIM 탐색 방법을 알게 되면 WMI를 통해 노출된 컴퓨터 및 소프트웨어 리소스를 알아내는 데 도움이 되며,
2. 관리 리소스의 청사진(클래스 정의)를 이해하는 방법을 알게 되면 관리 리소스에서 실행되는 작업을 알아내는 데 도움이 되기 때문입니다.

두 가지 이유 모두 여러분이 사용하는 WMI 도구에 관계없이 적용됩니다. 이것은 WMI 스크립팅 라이브러리를 사용하든 WMI 명령줄 도구(wmic.exe)를 사용하든 엔터프라이즈 관리 응용 프로그램을 사용하든지 간에 CIM을 탐색하고 CIM 클래스를 해석하는 방법을 알아야 한다는 의미입니다.

CIM을 배워야 하는 또 다른 중요한 이유는 CIM은 WMI 관리 리소스에 대한 훌륭한 설명서이기 때문입니다. 물론 WMI 클래스에 대한 자세한 정보가 필요하면 WMI SDK를 사용할 수 있습니다. 그렇지만 WMI 클래스에 대한 자세한 정보가 필요하지 않다면 어떨까요? 실행 중인 Microsoft Windows 버전에서 특정 클래스, 메서드, 속성이 지원되는지 여부만 알고 싶다고 가정하고, 대상 컴퓨터의 CIM을 살펴 봅시다.

예를 들어 흔히 "TechNet의 Script Center 에 있는 Join Computer to a Domain 스크립트가 왜 Windows 2000에서 실행되지 않습니까?"라고 묻습니다. 대답은 Win32_ComputerSystem 클래스(스크립트에 사용된 WMI 클래스)는 Windows 2000에서 JoinDomainOrWorkGroup 메서드를 지원하지 않기 때문입니다. Windows XP 및 Windows Server 2003에 기본 제공되는 WMI 버전에서 JoinDomainOrWorkGroup 메서드는 Win32_ComputerSystem 클래스에 추가되었습니다.

그러면 이것을 어떻게 배울까요? 한 가지 방법은 1부에 있는 WMI 도구 모음을 사용하는 것입니다. 두 번째, 더욱 강력하고 유연성이 큰 방법은 WMI 스크립팅 라이브러리를 사용하는 것입니다. WMI의 정말 멋진 기능 중 하나는 WMI 스크립팅 라이브러리를 사용하여 WMI에 대해서 배울 수 있다는 것입니다. 맞는 말입니다. WMI 스크립트를 작성하여 WMI 관리 리소스를 검색할 때와 같은 방식으로, WMI 스크립트를 작성하여 WMI에 대한 갖가지 흥미로운 정보를 배울 수 있습니다. WMI 스크립트를 작성하여 CIM 리포지토리의 모든 네임스페이스와 클래스를 나열할 수 있습니다. 스크립트를 작성하여 WMI 사용 컴퓨터에 설치된 모든 공급자를 나열할 수 있습니다. WMI 스크립트를 작성하여 관리 리소스 클래스 정의를 검색할 수도 있습니다.

기존 도구를 사용할지 아니면 자체 도구를 만들지에 관계없이, CIM 리포지토리의 구조, 해당 내용, 관리 리소스 클래스 정의 해석 방법 등에 대해 기본적인 내용을 알아야 합니다. 그러므로 CIM 리포지토리 관리를 위한 WMI의 청사진을 자세히 살펴보고 1부에서 다루다 만 내용부터 살펴봅시다. WMI 스크립팅 라이브러리를 사용하여 WMI 구성 정보 및 관리 리소스 클래스 정의를 검색하는 방법에 대해 계속 설명할 것입니다.

관리 청사진

1부에서는 각기 다른 원본의 구성 및 관리 정보가 스키마와 함께 일정하게 나타날 수 있으며, CIM 리포지토리는 WMI용 스키마라는 개념을 토대로 한다고 설명했습니다. 스키마를 실제 세계에 존재하는 어떤 물체를 나타내는 청사진 또는 모델로 생각해 보십시오. 건축 도면 모델이 집 같은 실제 구조를 모델링하는 것과 마찬가지로, WMI CIM은 하드웨어, 운영 체제 및 컴퓨터를 구성하는 소프트웨어를 모델링합니다. CIM은 WMI용 데이터 모델입니다.

참고   CIM 리포지토리는 데이터를 저장할 수 있지만, 주요 용도는 관리 환경을 모델링하는 것입니다. CIM은 정해진 양의 관리 정보를 저장하도록 고안된 것이 아니며, 데이터의 대부분은 요청시 WMI 공급자에서 동적으로 검색됩니다. 단, WMI 작업 데이터는 예외입니다. 네임스페이스 정보, 공급자 등록 정보, 관리 리소스 클래스 정의 및 영구 이벤트 구독 등과 같은 WMI 작업 데이터는 CIM 리포지토리에 저장됩니다.

그림 1에서는 CIM 리포지토리의 내부 구조 및 조직을 개념적으로 보여줍니다. 그림 1에서처럼 CIM은 클래스를 사용하여 데이터 모델을 만듭니다. CIM에는 Windows Server 2003에서 카운트한 마지막 5000번째 장소 내의 도표에 있는 11개 이상의 클래스가 들어 있습니다. ????스키마가 거의 5000개의 클래스로 이루어진 복잡한 망이라는 사실은 WMI 스크립팅 분야에서 주로 학문적으로 다루어집니다. 가장 중요한 것은 CIM 리포지토리는 WMI를 통해 노출된 모든 관리 가능한 리소스와 WMI 관리 환경을 정의하는 클래스 저장소라는 것입니다.

제대로 WMI 스키마를 탐색하고 해석하기 위해서는 그림 1에 있는 세 가지 중요한 CIM 개념을 이해해야 합니다.

1. CIM 리포지토리는 여러 네임스페이스로 나누어져 있습니다.
2. 각 네임스페이스에는 시스템 클래스, 핵심 및 공통 클래스, 확장 클래스 등과 같은 클래스 그룹이 하나 이상 있습니다.
3. 세 가지 주요 클래스 형식은 추상 클래스, 정적 클래스, 동적 클래스입니다. 추상 클래스는 새로운 추상 및 비추상 클래스를 파생시키는(정의하는) 데 사용되는 템플릿으로, 관리 리소스 인스턴스 검색에는 사용할 수 없습니다. 정적 클래스는 실제적으로 CIM 리포지토리에 저장되는 데이터, 즉 WMI 구성 및 작업 데이터 중 가장 일반적인 데이터를 정의합니다. 동적 클래스는 공급자에서 동적으로 검색되는 WMI 관리 리소스를 모델링하는 클래스입니다. 연결 클래스라는 네 번째 클래스 형식도 지원됩니다. 연결 클래스는 두 클래스 또는 관리 리소스 사이의 관계를 설명하는 추상, 정적, 또는 동적 클래스입니다. CIM 클래스 형식에 대해서는 너무 신경쓰지 않아도 됩니다. 잠시 후 CIM 클래스 유형에 대해서 실질적인 내용을 다룹니다.

이제 이 CIM 개념을 각각 자세히 살펴봅시다.

그림 1. CIM 리포지토리의 구조 보기 WMI 스키마

참고   CIM은 실제적으로 Windows XP 및 Windows Server 2003의 %SystemRoot%\system32\wbem\Repository\FS\objects.data라는 이름의 파일에 있습니다. Windows 2000 및 Windows NT 4.0 서비스 팩 4는 CIM을 %SystemRoot%\system32\wbem\Repository\cim.rep에 저장합니다. 그리고 Windows Millennium Edition(ME), Windows 98 및 Windows 95 OSR 2.5 운영 체제에서는 CIM을 %windir%\system\wbem\Repository\cim.rep에 저장합니다.

정의된 네임스페이스

CIM 클래스는 네임스페이스로 이루어집니다. 네임스페이스는 CIM에서 사용하는 분할 방법으로, 관리 리소스 클래스 정의의 범위와 표시 유형을 제어합니다. CIM의 각 네임스페이스에는 특정 기술 또는 관리 영역을 표시하는 관련 클래스의 논리적인 그룹이 있습니다. 네임스페이스 내의 모든 클래스는 고유 클래스 이름을 가지고 있어야 하며, 하나의 네임스페이스 내의 클래스는 다른 네임스페이스의 클래스에서 파생될 수 없습니다. 바로 이런 이유로 여러 네임스페이스에 정의되어 있는 동일한 시스템, 핵심 및 공용 클래스를 찾을 수 있습니다.

Windows 관리 리소스를 모델링하는 클래스 대부분은 root/cimv2 네임스페이스에 있습니다. 그렇지만 그림 1에서 알 수 있듯이, 여러분이 알아야 하는 네임스페이스는 root\cimv2만이 아닙니다. 예를 들면 이벤트 로그, 성능 카운터, Windows Installer 및 Win32 공급자 모두 root\cimv2 네임스페이스에 자체 관리 리소스 클래스 정의를 저장합니다. 한편 레지스트리 공급자는 root\default 네임스페이스에 해당 클래스 정의를 저장합니다. 그리고 새로운 Windows Server 2003 DNS 공급자는 root\MicrosoftDNS 네임스페이스에 관리 리소스 클래스 정의를 저장합니다.

네임스페이스 사용

그러면 네임스페이스는 WMI 스크립트에 어떻게 영향을 미칠까요? 모든 WMI 스크립트는 지난 달에 간단히 다루었던 초기 연결 단계의 일부로서 다음과 같이 네임스페이스에 연결됩니다.

strComputer = "."  
Set wbemServices = GetObject("winmgmts:\\" & strComputer)  

위와 같이 대상 네임스페이스를 지정하지 않으면 스크립트는 다음과 같은 레지스트리 설정으로 식별되는 네임스페이스에 연결됩니다.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\Scripting\Default Namespace.

%PATH% 환경 변수가 해당 운영 체제에 설정되는 것처럼 기본 네임스페이스는 WMI 스크립팅에 설정됩니다. 명령의 정규화된 경로를 지정하지 않고 명령 프롬프트를 통해 명령을 제출하면 운영 체제는 %PATH% 환경 변수를 사용하여 해당 명령의 실행 파일을 찾습니다. 운영 체제가 파일을 찾지 못하면 오류가 발생합니다.

마찬가지로 WMI 스크립트에서 관리 리소스를 검색할 때 CIMOM(WMI 서비스)은 네임스페이스가 전혀 지정되지 않은 경우 기본 네임스페이스에서 관리 리소스의 청사진(클래스 정의)을 찾습니다. CIMOM이 기본 네임스페이스에서 관리 리소스 클래스 정의를 찾을 수 없으면 WBEM_E_INVALID_CLASS(0x80041010) 오류가 발생합니다.

참고   기본 네임스페이스 설정과 root\DEFAULT 네임스페이스를 혼동하지 마십시오. 이 두 설정은 물론 root\DEFAULT를 기본 네임스페이스로 설정하지 않는 한 관련이 없습니다.

처음에 root\cimv2 네임스페이스는 스크립팅용 기본 네임스페이스로 구성되지만, 기본 스크립팅 네임스페이스는 쉽게 바꿀 수 있습니다. 그러므로 기본 설정을 받아들이지 말고 대신 WMI 스크립트에서 관리 리소스의 네임스페이스를 항상 식별해야 합니다. 지난 달 우리 조언을 그대로 따르면 네 가지 모든 목록(그리고 본 기사의 목록 1과 2)의 연결 단계는 다음과 같이 작성됩니다.

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

대상 네임스페이스를 연결 문자열에 추가하면 CIMOM은 CIM에서 관리 리소스의 클래스 정의를 찾게 되는데, 이것은 정규화된 경로를 사용하여 파일을 찾을 장소를 정확히 알 수 있는 것과 비슷합니다. 대상 네임스페이스를 지정하면 기본 네임스페이스는 사용되지 않습니다.

스크립팅용 기본 네임스페이스 관리

Win32_WMISetting 클래스와 함께 WMI 스크립팅 라이브러리를 사용하면 목록 3과 4에 있는 스크립팅용 기본 네임스페이스를 읽고 변경할 수 있습니다. Win32_WMISetting은 WMI 서비스에 대한 작업 매개 변수를 모델링하는 동적 클래스입니다. 스크립팅용 기본 네임스페이스를 나타내는 쓰기 가능 속성은 ASPScriptDefaultNamespace입니다.

목록 3은 우리가 지금까지 사용한 것과 동일한 세 가지 WMI 스크립팅 단계(연결, 검색, 표시)를 수행하며, 이 때 한 가지 큰 변화가 있습니다. 앞에서 권장한 것처럼 Microsoft Visual Basic, Scripting Edition(VBScript)의 GetObject 함수에 전달된 WMI 연결 문자열에서 Win32_WMISetting 클래스에 대한 정규화된 네임스페이스를 지정합니다. 그러면 여기에서 여러분은 Microsoft가 자신의 권고를 따르지 않았다고 생각할 것입니다. 우리는 목록 3의 네임스페이스 권장 사항을 따를 뿐만 아니라 앞으로 이 사항을 기준으로 네임스페이스를 정규화하게 됩니다. 물론 WMI 스크립트에서 클래스가 적합하지 않다는 오류를 피하려고 하는 경우 이 문제는 중요합니다.

목록 3. WMI 및 VBScript를 사용한 스크립팅용 기본 네임스페이스 검색

strComputer = "."   

Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colWMISettings = objWMIService.InstancesOf("Win32_WMISetting")

For Each objWMISetting in colWMISettings
    Wscript.Echo "스크립팅용 기본 네임스페이스: " & _
                 objWMISetting.ASPScriptDefaultNamespace 
Next  

목록 3에서 예제 스크립트를 실행하려면 스크립트를 복사하여 원하는 텍스트 편집기에 붙여넣은 후 .vbs 확장명으로 스크립트를 저장하고 그림 2에 있는 스크립트를 실행합니다. 로컬 컴퓨터의 기본 네임스페이스가 콘솔에 알려지는지 확인해야 합니다.

그림 2. GetDefaultNamespace.vbs 출력

스크립팅용 기본 네임스페이스를 설정하려면 목록 3에 있는 것과 동일한 스크립팅 단계를 실행해야 합니다. 이 때 한 가지 중요한 변경 사항이 있으며, 스크립트의 줄 수를 세는 경우라면 두 가지 바뀐 점이 있습니다. WMI 스크립팅 라이브러리의 SWbemObject를 사용하여 WMI 관리 리소스의 인스턴스에서 속성을 읽는 대신 SWbemObject을 사용하여 속성을 설정함으로써 SWbemObject의 Put_ 메서드를 호출하여 WMI 관리 리소스에 변경 사항을 적용합니다. Win32_WMISetting의 경우에서처럼 대상 WMI 관리 리소스의 인스턴스가 하나만 존재해도 SWbemServices InstancesOf 메서드는 항상 SWbemObjectSet 컬렉션을 반환하므로 설정 및 적용 작업은 목록 4의 For Each 루프에서 실행됩니다.

목록 4. WMI 및 VBScript를 사용한 스크립팅용 기본 네임스페이스 설정

strComputer = "."   

Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colWMISettings = objWMIService.InstancesOf("Win32_WMISetting")

For Each objWMISetting in colWMISettings
        objWMISetting.ASPScriptDefaultNamespace = "root\cimv2"
        objWMISetting.Put_
Next  

3부에서 WMI 스크립팅 라이브러리에 대해서 자세히 다룰 예정이므로 WMI 스크립팅 라이브러리에 너무 몰두해 있지 마십시오. 이제 CIM을 다시 살펴봅시다.

네임스페이스 목록

지금까지 우리는 같은 WMI 스크립팅 기술을 사용하여 동적 WMI 관리 리소스 인스턴스를 검색했습니다. 예를 들어 1부에서는 같은 스크립트 템플릿을 사용하여 총 실제 메모리, 서비스, 이벤트 로그 레코드 및 프로세스를 검색했습니다. 그리고 2부에서는 서비스, 운영 체제 정보 및 스크립팅용 기본 네임스페이스를 검색했습니다. 알 수 있듯이, 같은 WMI 스크립팅 기술을 사용하여 CIM에서 네임스페이스 정보를 검색할 수 있습니다. 관리 리소스 스크립트의 경우에서처럼, 이 때 스크립트에서 대상 클래스 이름을 바꿔야 합니다.

네임스페이스 정보는 CIM 안에 __NAMESPACE 클래스의 정적 인스턴스로 저장됩니다. __NAMESPACE 클래스는 앞서 간단히 정의한 정적 클래스의 예제입니다. 필요시 공급자로부터 검색하는 동적 WMI 관리 리소스와는 달리, 정적 클래스는 CIM에 저장되며, WMI 공급자를 사용하지 않고도 CIM에서 직접 검색됩니다. 목록 5에서는 __NAMESPACE 클래스를 사용하여 루트 네임스페이스 바로 아래의 모든 네임스페이스를 검색하고 반향시킵니다.

목록 5. WMI 및 VBScript를 사용한 CIM 네임스페이스 검색

strComputer = "."   

Set objServices = GetObject("winmgmts:\\" & strComputer & "\root")
Set colNameSpaces = objServices.InstancesOf("__NAMESPACE")

For Each objNameSpace In colNameSpaces
    WScript.Echo objNameSpace.Name
Next  

그림 3에는 Windows Server 2003 컴퓨터에서 목록 5를 실행시킨 결과가 나타납니다. 네임스페이스 목록은 대상 컴퓨터에 설치된 Windows 및 WMI의 버전에 따라 달라집니다.

그림 3. GetNamespaces.vbs 출력

알 수 있듯이 목록 5는 대상 컴퓨터에서 사용할 수 있는 모든 네임스페이스를 전부 나타내지 않으며 지정된 하나의 네임스페이스 아래의 네임스페이스만 검색하여 표시합니다. 로컬 또는 원격 WMI 사용 가능 컴퓨터에서 모든 네임스페이스를 반향시키려면, 목록 5를 수정하여 각 네임스페이스를 재귀적으로 연결하고 나열해야 합니다. 다행히 이 작업은 목록 6에서 알 수 있듯이 생각만큼 어렵지 않습니다.

목록 5를 목록 6에 있는 재귀적 네임스페이스 스크립트로 변경하려면 서브루틴 내의 원본 스크립트 본문을 구현하고 CIM에서 검색한 각각의 네임스페이스 인스턴스에 대한 서브루틴을 호출할 수 있는 장치를 제공해야 합니다. 목록 6에서는 다음 단계를 실행하여 이 작업을 완수합니다.

1. 목록 6은 대상 컴퓨터의 이름으로 strComputer를 초기화하는 작업부터 시작합니다. WMI에서 하나의 마침표(".")는 로컬 컴퓨터를 나타냅니다. strComputer에 할당된 값을 관리 기능이 있는 도메인의 WMI 사용 가능 컴퓨터로 변경할 수 있습니다.
2. 스크립트는 재귀적 서브루틴 EnumNameSpaces를 호출하고 연결할 초기 네임스페이스를 식별하는 문자열 "root"를 서브루틴에 전달합니다.
3. EnumNameSpaces 서브루틴의 본문은 목록 5와 같지만, 한 가지 중요한 변경 사항이 있습니다. 서브루틴을 단계별로 살펴봅시다.
   1. EnumNameSpaces는 서브루틴의 단일 인수 strNameSpace의 값을 반향시키면 시작됩니다. strNameSpace는 서브루틴이 호출될 때마다 연결 문자열에 사용되는 네임스페이스를 식별합니다.
   2. VBScript에서 GetObject 함수를 사용하면 서브루틴은 서브루틴의 strNameSpace 인수가 식별한 네임스페이스에 연결됩니다.
   3. 대상 컴퓨터의 네임스페이스 및 WMI 서비스에 연결한 후 서브루틴은 strNameSpace가 참조한 네임스페이스 바로 아래의 모든 네임스페이스 인스턴스를 검색합니다.
   4. For Each 루프를 사용하면, 서브루틴은 현재 연결된 네임스페이스 바로 아래의 네임스페이스 인스턴스를 나열합니다. 그러나 단순히 자식(또는 서브) 네임스페이스를 반향시키는 것이 아니라, 각 자식(또는 서브) 네임스페이스의 이름이 현재 네임스페이스에 연결되고, 현재 네임스페이스는 EnumNameSpaces 서브루틴의 새로운 호출에 전달됩니다. 이 서브루틴 단계는 모든 네임스페이스 인스턴스가 나열될 때까지 반복됩니다.

목록 6. WMI 및 VBScript를 사용한 모든 CIM 네임스페이스 검색

strComputer = "."   

Call EnumNameSpaces("root")

Sub EnumNameSpaces(strNameSpace)

  WScript.Echo strNameSpace

  Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\" & strNameSpace)
  Set colNameSpaces = objWMIService.InstancesOf("__NAMESPACE")

  For Each objNameSpace In colNameSpaces
    Call EnumNameSpaces(strNameSpace & "\" & objNameSpace.Name)
  Next

End Sub  

그림 4에는 같은 Windows Server 2003 컴퓨터에서 목록 6을 실행시킨 결과가 나타납니다.

그림 4. GetAllNamespaces.vbs 출력

정의된 클래스 카테고리

그림 1에서 볼 수 있듯이, CIM 구성에 사용되는 일반 클래스 카테고리는 시스템, 핵심 및 공용, 확장 세 가지입니다.

시스템 클래스

시스템 클래스는 네임스페이스 구성, 네임스페이스 보안, 공급자 등록, 이벤트 구독 및 알림 등과 같은 내부 WMI 구성 및 작업을 지원하는 클래스입니다. CIM 검색시, 각 시스템 클래스의 이름 앞에 오는 두 개의 밑줄로 시스템 클래스를 쉽게 식별할 수 있습니다. 예를 들어 그림 1에 있는 __SystemClass, __Provider 및 __Win32Provider 클래스는 시스템 클래스입니다. 앞에서 살펴본 __NAMESPACE 클래스는 시스템 클래스의 또 다른 예입니다.

시스템 클래스는 추상 또는 정적 클래스입니다. 추상 시스템 클래스는 다른 추상 또는 정적 시스템 클래스를 파생시키는(정의하는) 데 사용되는 템플릿입니다. 정적 시스템 클래스는 실제적으로 CIM 리포지토리에 저장되는 작업 데이터 및 WMI 구성을 정의합니다. 예를 들어 __Win32Provider 시스템 클래스는 CIM에 저장된 공급자 등록 정보를 정의합니다. CIMOM(WMI 서비스)는 CIM에 저장된 공급자 등록 정보를 사용하여 동적 관리 리소스에 대한 요청을 해당 공급자에 매핑합니다.

앞에서 __NAMESPACE 시스템 클래스를 사용했을 때처럼, 동일한 WMI 스크립팅 기술을 사용하여 CIM에 저장된 시스템 클래스의 정적 인스턴스를 검색할 수 있습니다. 예를 들어 목록 7은 root\cimv2 네임스페이스에 등록된 모든 __Win32Provider 인스턴스를 검색하고 표시합니다.

목록 7. WMI 및 VBScript를 사용하여 root\cimv2 네임스페이스에 등록된 Win32 공급자 검색

strComputer = "."   

Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colWin32Providers = objWMIService.InstancesOf("__Win32Provider")

For Each objWin32Provider In colWin32Providers
    WScript.Echo objWin32Provider.Name
Next 
 

WMI에 대한 책을 집필하지 않는 한, WMI 스크립트에서 시스템 클래스를 사용할 가능성은 적습니다. 한 가지 예외가 있다면 WMI 모니터링 스크립트입니다. WMI 모니터링 스크립트는 WMI 이벤트 구독 스크립트입니다. 이벤트는 어떤 흥미로운 사실이 WMI 관리 리소스로 바뀌었음을 나타내는 실시간 알림입니다. WMI 이벤트 구독 및 알림에 대해서는 나중에 다룹니다.

참고   그 때까지 기다리지 못하는 분들을 위해서 알려드리면, 가장 일반적인 세 가지 WMI __Event 시스템 이벤트는 __InstanceCreationEvent, __InstanceModificationEvent, __InstanceDeletionEvent입니다. 여기에서 이러한 시스템 이벤트를 다루지는 않지만 TechNet Script Center의 Monitoring 섹션에서 이러한 시스템 클래스의 사용법을 알려주는 에제 모니터링 스크립트를 볼 수 있습니다.

핵심 및 공용 클래스

핵심 및 공용 클래스는 두 가지 역할을 합니다. 첫째, 핵심 및 공용 클래스는 Microsoft 직원과 같은 시스템 및 응용 프로그램 소프트웨어 개발자가 기술 관련 확장 클래스를 파생시키고 만드는 추상 클래스를 나타냅니다. 둘째, 특정 관리 영역에 대해 공통되지만 특정 기술 또는 구현과는 독립적인 리소스를 정의합니다. DMTF(Distributed Management Task Force) 는 핵심 및 공용 클래스 집합을 정의하고 유지 관리하며, 이 집합은 CIM_prefix로 식별할 수 있습니다. 그림 1의 CIM_로 시작하는 네 개의 클래스는 핵심 및 공용 클래스입니다.

root\cimv2 네임스페이스에 정의되어 있는 대략 275개의 핵심 및 공용 클래스 중에서 몇 개의 예외를 제외하고는 모두 추상 클래스입니다. 이것은 어떤 의미입니까? WMI 스크립트에서는 핵심 및 공용 클래스(CIM_로 시작하는 클래스)를 사용할 가능성이 거의 없음을 의미합니다. 그 이유는 무엇일까요? 추상 클래스의 인스턴스를 검색할 수 없기 때문입니다. 추상 클래스는 새로운 클래스에 대한 기본 클래스로만 사용 가능합니다. 핵심 및 공용 클래스 중 271개는 추상 클래스이므로, 이들 클래스는 주로 기술 관련 확장 클래스를 만드는 소프트웨어 개발자가 사용합니다.

그렇다면 예외는 무엇입니까? 275개의 핵심 및 공용 클래스 중 4개는 추상 클래스가 아니라, Win32 공급자(cimwin32.dll)를 사용하여 관리 리소스 인스턴스를 검색하는 동적 클래스입니다. 네 개의 동적 클래스는 CIM_DataFile, CIM_DirectoryContainsFile, CIM_ProcessExecutable, CIM_VideoControllerResolution입니다.

확장 클래스

확장 클래스는 시스템 및 응용 프로그램 소프트웨어 개발자가 만드는 기술 관련 클래스입니다. 그림 1의 Win32_BaseService, Win32_Service, Win32_SystemServices, Win32_ComputerSystem 클래스는 Microsoft 확장 클래스입니다. root\cimv2 네임스페이스에 있는 Microsoft 확장 클래스는 Win32_prefix로 식별할 수 있습니다. 그렇다고 모든 Microsoft 확장 클래스가 Win32_로 시작해야 한다고 결론을 내려서는 안됩니다. 실제로 그렇지 않기 때문입니다. 예를 들어 StdRegProv 클래스가 Microsoft의 레지스트리 관리 작업용 확장 클래스라는 사실에도 불구하고 root\DEFAULT 네임스페이스에 정의된 StdRegProv 클래스는 Win32_로 시작하지 않습니다. 여러분이 질문을 하기 전에 고백하자면, 우리는 StdRegProv 클래스가 root\cimv2가 아닌 root\DEFAULT 네임스페이스에 정의되는 이유를 알지 못합니다.

이 기사를 쓰는 시점에는 root\cimv2 네임스페이스에 대략 463개의 Win32 확장 클래스가 정의되어 있습니다. 463개의 Win32 클래스 중에서 68개는 추상 클래스이며 나머지 395개는 동적 클래스입니다. 이것은 어떤 의미입니까? 확장 클래스는 WMI 스크립트에서 사용하게 될 주요 클래스 카테고리라는 것을 의미합니다.

참고   여기에 제공된 클래스 통계는 Windows Server 2003의 베타 버전을 근거로 한 것이며, 일반적인 CIM 개념을 도식화하기 위한 것일 뿐입니다. 그러므로 통계는 Windows 버전, WMI 버전 및 설치된 소프트웨어 등과 같은 몇 가지 요인에 따라 달라집니다.

클래스 목록

그렇다고 깜짝 놀랄 필요는 없습니다. 네임스페이스 안에 정의된 모든 클래스를 검색할 수 있는 스크립트를 작성할 수 있습니다. 예를 들어 목록 8에는 root\cimv2 네임스페이스에 정의된 모든 클래스가 있습니다. 그러나 SWbemServices InstancesOf 메서드를 사용한 이전의 모든 스크립트와는 달리, 목록 8은 다른 메서드 SubclassesOf를 사용하며, 이 메서드 역시 WMI 스크립팅 라이브러리의 SWbemServices 개체에서 제공합니다.

메서드의 이름이 나타내듯이, SubclassesOf는 지정된 부모(또는 슈퍼) 클래스의 모든 자식(또는 서브) 클래스를 반환합니다. 부모 클래스가 전혀 제공되지 않으면 네임스페이스를 반환합니다. InstancesOf처럼 SubclassesOf는 SWbemObjectSet 컬렉션 내의 모든 서브클래스를 반환하며, 이 때 컬렉션 내의 각 항목은 하나의 클래스를 나타내는 SWbemObject입니다.

목록 8에서 또 다른 중요한 차이점은 objClass입니다. For Each 루프 본문에서 반향된 Path_.Path 속성. For Each 루프를 살펴보고 정확히 그 의미를 알아봅시다. For Each 루프는 SWbemServices SubclassesOf 메서드에서 반환한 SWbemObjectSet(colClasses) 컬렉션에 있는 각각의 SWbemObject(objClass)를 나열합니다. 각각의 SWbemObject는 root\cimv2 네임스페이스에 있는 개별 클래스를 나타냅니다.

이 점이 혼동을 줄 수 있습니다. 관리 리소스의 청사진(클래스 정의)에서 정의한 속성을 표시하는 이전의 모든 스크립트와는 달리, Path_는 WMI 스크립팅 라이브러리의 SWbemObject에서 제공하는 속성입니다. 이를 이해하기 위해서는 SWbemObject를 사용 중인 상황에 대해서 생각해야 합니다. SWbemObject를 사용하여 관리 리소스 인스턴스에 액세스하는 중입니까? 아니면 SWbemObject를 사용하여 관리 리소스의 클래스 정의에 액세스하는 중입니까?

SWbemObject를 사용하여 관리 리소스 인스턴스에 액세스하는 중이라면 SWbemObject를 사용하여 관리 리소스의 청사진(클래스 정의)에서 정의한 속성 및 메서드에 액세스할 가능성이 큽니다. SWbemObject를 사용하여 지원 속성, 메서드 및 한정자 같은 자세한 클래스 정보를 얻는다면 SWbemObject 자체가 제공하는 속성 및 메서드를 사용할 가능성이 큽니다. 그 대표적인 속성이 Path_입니다.

Path_는 실제로 Path 속성을 제공하는 SWbemObjectPath라는 WMI 스크립팅 라이브러리 개체를 참조합니다. SWbemObjectPath Path 속성에는 SWbemObject(목록 8의 objClass)에서 참조하는 클래스에 대한 정규화된 경로가 있습니다. 3부에서 자세히 다룰 것이므로 지금은 스크립팅 개체에 너무 신경쓰지 마십시오.

목록 8. WMI 및 VBScript를 사용하여 the root\cimv2 네임스페이스에 정의된 모든 클래스 검색

strComputer = "."   

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

For Each objClass In colClasses
    WScript.Echo objClass.Path_.Path
Next  

Windows Server 2003 컴퓨터에서 목록 8을 실행시키면 914개의 클래스로 이루어진 긴 목록이 나타나며, 그 일부가 그림 5에 나타나 있습니다.

그림 5. GetClasses.vbs 출력

물론 목록 8을 수정하여 다른 네임스페이스의 클래스를 나열할 수 있으며, 이 때 스크립트의 대상 네임스페이스를 변경하기만 하면 됩니다. 또한 findstr.exe 명령과 함께 목록 8을 사용하여 클래스를 검색할 수도 있습니다. findstr.exe 명령에 익숙하지 않은 분들을 위해 설명하자면, findstr.exe는 파일에서 문자열을 검색하는 명령줄 도구입니다.

예를 들어 실행 중인 Windows 버전에서 새로운 Windows XP 및 Windows Server 2003 Win32_TSSessionSetting 클래스를 지원하는지 여부를 알아야 합니다. 다음 명령을 사용하여 Win32_TSSessionSetting 클래스가 root\cimv2 네임스페이스에 존재하는지 알아낼 수 있습니다.

C:\Scripts> cscript GetClasses.vbs |findstr /I "win32_tssessionsetting"  

여기에 몇 가지 시나리오를 더 시도해 볼 수 있습니다.

• root\cimv2 네임스페이스의 모든 클래스를 나열합니다.

  C:\Scripts> cscript GetClasses.vbs |findstr /I "__"  
  

• root\cimv2 네임스페이스의 모든 핵심 및 공용 클래스를 나열합니다.

  C:\Scripts> cscript GetClasses.vbs |findstr /I "CIM_"  
  

• root\cimv2 네임스페이스의 모든 Win32 확장 클래스를 나열합니다.

  C:\Scripts> cscript GetClasses.vbs |findstr /I "Win32_"  
  

• root\cimv2 네임스페이스에서 "process"라는 문자열이 포함된 모든 클래스를 나열합니다.

  C:\Scripts> cscript GetClasses.vbs |findstr /I "process"  

정의된 CIM 클래스 형식

이 때 클래스는 CIM 리포지토리에서 기본 초석이 됩니다. WMI 구성 정보 및 WMI 관리 리소스는 하나 이상의 클래스로 정의됩니다. Active Directory 스키마와 마찬가지로, CIM 클래스는 자식 클래스가 부모 클래스로부터 속성, 메서드 및 한정자를 상속하는 계층 구조를 이룹니다(속성, 메서드 및 한정자에 대해서는 염려하지 마십시오. 다음 섹션에서 다룹니다). 예를 들어 그림 1에서 볼 수 있듯이, Win32_Service 동적 클래스는 Win32_BaseService 추상 클래스로부터 상속받고, Win32_BaseService 추상 클래스는 CIM_Service 추상 클래스로부터 상속받고, CIM_Service 추상 클래스는 CIM_LogicalElement 추상 클래스로부터 상속받고, CIM_LogicalElement 추상 클래스는 CIM_ManagedSystemElement 추상 클래스로부터 상속받습니다. 관리 메서드를 최종적으로 정의하는 것은 바로 관리 리소스의 클래스 계층 구조에 있는 클래스의 합계입니다.

앞에서 설명했듯이, 세 가지 주요 클래스 형식은 추상 클래스, 정적 클래스, 동적 클래스입니다.

추상 클래스

추상 클래스는 새로운 클래스 정의에 사용되는 템플릿입니다. Active Directory 스키마의 추상 클래스처럼, CIM 추상 클래스는 다른 추상, 정적 및 동적 클래스의 기본 클래스 역할을 합니다. 거의 모든 WMI 관리 리소스 클래스 정의는 하나 이상의 추상 클래스에서 파생되거나 작성됩니다.

클래스의 Abstract 한정자를 살펴보면 추상 클래스를 식별할 수 있습니다. 추상 클래스는 Abstract 한정자를 정의하고 Abstract 한정자의 값을 True로 설정해야 합니다. 이 기사의 끝에 있는 부록 목록 A는 WMI 스크립팅 라이브러리를 사용하여 root\cimv2 네임스페이스에 정의된 모든 추상 클래스를 나열하는 방법을 알려줍니다.

추상 클래스 형식을 가장 흔히 사용하는 경우는 핵심 및 공통 클래스를 정의할 때입니다. 추상 클래스의 인스턴스를 검색할 수 없기 때문에 추상 클래스는 WMI 스크립트에서 거의 사용되지 않습니다.

정적 클래스

정적 클래스는 CIM 리포지토리에 실제로 저장되는 데이터를 정의합니다. 정적 클래스에는 동적 클래스와 비슷한 인스턴스가 있습니다. 그러나 정적 클래스의 인스턴스는 CIM 리포지토리에 저장됩니다. 마찬가지로 정적 클래스 인스턴스는 CIM에서 직접 검색됩니다. 정적 클래스 인스턴스는 공급자를 사용하지 않습니다.

클래스의 한정자를 살펴보면 정적 클래스를 식별할 수 있습니다. 그러나 특정 한정자의 존재로 식별되는 추상 및 동적 클래스 형식과는 달리, 정적 클래스는 Abstract 및 Dynamic 한정자의 부재로 식별됩니다.

정적 클래스 형식을 가장 흔히 사용하는 경우는 시스템 클래스를 정의할 때입니다. 정적 클래스는 WMI 스크립트에서 거의 사용되지 않습니다.

동적 클래스

동적 클래스는 공급자에서 동적으로 검색되는 WMI 관리 리소스를 모델링하는 클래스입니다.

클래스의 Dynamic 한정자를 살펴보면 동적 클래스를 식별할 수 있습니다. 동적 클래스는 Dynamic 한정자를 정의하고 Dynamic 한정자의 값을 Ture로 설정해야 합니다. 이 기사 끝에 있는 부록 목록 B는 WMI 스크립팅 라이브러리를 사용하여 root\cimv2 네임스페이스에 정의된 모든 동적 클래스를 나열하는 방법을 알려줍니다.

동적 클래스 형식을 가장 흔히 사용하는 경우는 확장 클래스를 정의할 때입니다. 동적 클래스는 WMI 스크립트에서 가장 흔히 사용되는 클래스 형식입니다.

연결 클래스

연결 클래스라는 네 번째 클래스 형식도 지원됩니다. 연결 클래스는 두 클래스 또는 관리 리소스 사이의 관계를 설명하는 추상, 정적, 또는 동적 클래스입니다. 그림 1에 있는 Win32_SystemServices 클래스는 컴퓨터와 컴퓨터에서 실행 중인 서비스간의 관계를 설명하는 동적 연결 클래스의 예입니다.

클래스의 Association 한정자를 살펴보면 연결 클래스를 식별할 수 있습니다. 추상, 정적, 또는 동적 연결 클래스는 Association 한정자를 정의하고 Association 한정자의 값을 True로 설정해야 합니다.

클래스 해부

부러진 레코드판처럼 소리가 나는 위험을 감수할지언정 WMI를 통해 관리할 수 있는 모든 하드웨어 및 소프트웨어 리소스는 클래스에서 정의됩니다. 클래스는 개별 WMI 관리 리소스에 대한 청사진(또는 템플릿)이며, 리소스의 모든 인스턴스는 청사진을 사용합니다. 클래스는 컴퓨터에 있는 것을 나타냅니다. 그리고 컴퓨터에는 디스크, 이벤트 로그, 파일, 폴더, 메모리, 프린터, 프로세스, 프로세서, 서비스 등이 있기 때문에 WMI에는 디스크, 이벤트 로그, 파일, 폴더, 메모리, 프린터, 프로세스, 프로세서, 서비스 등에 대한 클래스가 있습니다. 예외가 존재하기는 하지만(예: __Event 추상 시스템 클래스), 스크립팅에 사용되는 대부분의 클래스는 실체와 직접 연결 가능합니다.

소위 청사진은 속성, 메서드, 한정자로 구성됩니다. 속성, 메서드, 한정자를 살펴보기 전에 관리 리소스 클래스 정의가 어디에서 기원하는지 간략하게 살펴봅시다.

Microsoft가 시스템 관리자가 Microsoft DNS 서버의 관리 및 모니터링에 사용할 수 있는 새로운 WMI 공급자를 만들기로 했다고 가정해 봅시다. 최소한 DNS 공급자 개발 팀은 공급자와 MOF(Managed Object Format) 파일 두 가지를 만들어야 합니다.

공급자는 WMI 인프라와 기저 관리 리소스(이 경우에는 Microsoft DNS 서버) 사이를 중개하는 동적 링크 라이브러리입니다. 공급자는 관리 리소스의 기본 API를 호출하여 WMI 요청을 서비스합니다.

MOF 파일에는 DNS 공급자가 제공하는 능력을 설명하는 클래스 정의가 들어 있습니다. MOF 파일은 DNS 서버와 공통적으로 연관된 리소스(예: 영역 파일 및 리소스 레코드)를 모델링하는 클래스를 사용하여 DNS 공급자의 능력을 설명합니다. DNS MOF 파일에 정의된 각각의 클래스는 특정 DNS 관련 리소스와 관련된 데이터(속성)와 리소스에서 실행할 수 있는 작업(메서드)를 정의합니다.

DNS 공급자를 설치하면 DNS 공급자 동적 링크 라이브러리가 운영 체제 및 WMI에 등록되고 DNS MOF 파일이 컴파일 과정에 들어가게 됩니다. 이 때 DNS 공급자의 클래스 정의가 CIM 리포지토리로 로드됩니다. 이 때 DNS 공급자는 스크립트를 포함해 모든 WMI 사용 가능 소비자가 사용할 수 있습니다.

Microsoft에서 새로운 Windows Server 2003용 DNS 공급자를 개발했다는 우리의 말은 사실이지만, 여기에서 기억하고 넘어가야 하는 중요한 사실은 관리 리소스 클래스 정의가 MOF 파일에서 유래했다는 것입니다. MOF 파일이 WMI와 관련이 있듯, MIB 파일은 SNMP와 관련이 있습니다.

MOF 파일은 DMTF(Distributed Management Task Force) 에서 만들고 유지 관리하는 MOF 언어를 기반으로 한 텍스트 파일입니다. 모든 관리 리소스의 클래스 정의 다음에는 그림 6처럼 잘 정의된 구조와 구문이 옵니다.

그림 6. 관리 리소스 클래스 정의의 구조

그림 6에서 볼 수 있듯이, 모든 관리 리소스 클래스 정의는 속성, 메서드, 한정자로 구성됩니다.

속성

속성은 관리 리소스를 설명하는 명사입니다. 클래스는 속성을 사용하여 관리 리소스의 ID, 구성 및 상태 등을 설명합니다. 예를 들어 서비스에는 이름, 표시 이름, 설명, 시작 유형 및 상태 등이 있습니다. Win32_Service 클래스에는 동일한 것이 있습니다.

각 속성에는 이름, 유형 및 선택적 속성 한정자가 있습니다. 목록 1에서처럼 WMI 스크립팅 라이브러리의 SWbemObject와 함께 속성 이름을 사용하여 관리 리소스의 속성을 액세스합니다.

메서드

메서드는 관리 리소스에 동작을 실행하는 동사입니다. 서비스로 무엇을 할 수 있을까요? 서비스를 시작하고 중지하고 일시 중지하고 다시 시작할 수 있습니다. 서비스를 시작, 중지, 일시 중지 및/또는 다시 시작할 수 있도록 하는 메서드가 있습니다. 전혀 놀라운 일이 아닙니다.

각 메서드에는 이름, 반환 유형, 선택적 매개 변수 및 선택적 메서드 한정자가 있습니다. 속성과 마찬가지로, WMI 스크립팅 라이브러리의 SWbemObject와 함께 메서드의 이름을 사용하여 메서드를 호출합니다.

모든 클래스가 메서드를 정의하는 것은 아닙니다.

한정자

한정자는 적용할 클래스, 속성, 또는 메서드에 대한 추가 정보를 제공하는 형용사입니다. 예를 들면 "클래스의 유형이 Win32_Service입니까?"라는 질문에 대해서 클래스의 Dynamic 한정자로 대답합니다. 단순히 정보를 검색하는 것 이상의 작업(예: 속성 수정 또는 메서드 호출)을 하는 WMI 스크립트를 작성하기 시작하면 한정자는 여러분이 호출하는 메서드나 업데이트 중인 속성의 작업 특성을 정의하므로 점점 중요해집니다. 그렇다면 한정자는 어떤 종류의 정보를 제공할까요?

클래스 한정자

클래스 한정자는 클래스에 대한 작업 정보를 제공합니다. 예를 들면, 다음과 같습니다.

• 앞에서 배웠듯이, Abstract, Dynamic 및 Association 한정자는 클래스 형식을 알려줍니다.
• Provider 한정자는 클래스를 서비스하는 공급자를 알려줍니다. 예를 들어 Win32_Service 클래스에 대한 Provider 한정자는 클래스가 CIMWin32 공급자 (cimwin32.dll)를 사용함을 알려줍니다. 반면 Win32_NTLogEvent 클래스는 Win32_NTLogEvent 클래스의 Provider 한정자가 나타내듯이 MS_NT_EVENTLOG_PROVIDER 공급자(ntevt.dll)를 사용합니다.
• Privileges 한정자는 클래스 사용에 필요한 특수 권한을 알려줍니다. 예를 들어 Win32_NTLogEvent 클래스의 Privileges 한정자는 SeSecurityPrivilege가 활성화된 다음 Win32_NTLogEvent 클래스를 사용하여 보안 로그를 관리해야 한다고 알려줍니다.

속성 한정자

속성 한정자는 각 속성에 대한 정보를 제공합니다. 예를 들면, 다음과 같습니다.

• CIMType 한정자는 속성의 데이터 형식을 알려줍니다.
• Read 한정자는 속성이 읽기 가능임을 알려줍니다.
• Write 한정자는 속성의 값을 수정할 수 있는지 아닌지 여부를 나타냅니다. 예를 들어 목록 4에서 수정한 Win32_WMISetting 클래스의 ASPScriptDefaultNamespace 속성은 쓰기 가능으로 표시됩니다. 반면 목록 1에서 반향된 모든 Win32_Service 속성은 읽기 전용으로 정의되며, 다시 말해 Write 한정자를 정의하지 않습니다.
• Key 한정자는 속성이 클래스의 키라는 것을 나타내며, 동일한 리소스의 컬렉션에 있는 관리 리소스의 고유 인스턴스를 식별하는 데 사용됩니다.

메서드 한정자

메서드 한정자는 각 메서드에 대한 정보를 제공합니다. 예를 들면, 다음과 같습니다.

• Implemented 한정자는 메서드에 공급자가 제공한 구현이 있다는 것을 나타叿䉍/᠀젇ࠅက麃．�מȀĀ＀�ÿ쐀䂬씀메서드 매개 변수 또는 반환 유형에 대한 허용 가능 값 집합을 정의합니다.
• Privileges 한정자는 메서드 호출에 필요한 특수 권한을 알려줍니다.

참고   여기에서 언급한 것보다 더 많은 한정자가 존재합니다. 전체 목록을 보려면 WMI SDK 의 WMI Qualifiers 항목을 참조하십시오.

그림 7에 있는 WMI Tester(wbemtest.exe) 도구를 사용하여 클래스의 속성, 메서드, 한정자를 살펴볼 수 있습니다. 물론 WMI 스크립팅 라이브러리를 사용하여 같은 정보를 검색할 수도 있습니다.

그림 7. WMI Tester(wbemtest.exe)를 사용한 Win32_Service 클래스 보기

클래스와 관리 리소스 비교

대부분의 WMI 속성 및 메서드는 합리적으로 이름이 잘 지어져 있습니다. 예를 들어 그림 8에서처럼 Win32_Service 클래스에서 정의한 속성 및 메서드와 서비스 속성 대화 상자를 비교하는 경우, Win32_Service.Name, Win32_Service.DisplayName, 또는 Win32_Service.Descritpion 안에 무엇이 들어 있는지 알아내기 힘듭니다.

그림 8. 서비스 속성 대화 상자와 Win32_Service 클래스 속성 및 메서드

그렇다면 왜 이러한 요소에 대해서 신경을 써야 할까요? 클래스는 WMI로 할 수 있는 일과 할 수 없는 일을 결정합니다. 서비스에 대한 클래스가 있다면 서비스를 관리할 수 있지만, 없으면 관리할 수 없습니다. WMI의 버전은 운영 체제마다 다르므로 속성 및 메서드는 중요합니다. Windows XP의 Win32_ComputerSystem 클래스에는 새로운 많은 속성 및 메서드가 있지만, Windows 2000의 Win32_ComputerSystem 클래스에는 없습니다. ADSI와는 달리, 작업이 진행되도록 하기 위해서는 대상 컴퓨터에서 WMI 속성 및 메서드를 사용할 수 있어야 하기 때문에 여러분은 WMI에 대해서 자세히 알아야 합니다.

원격 Windows 컴퓨터에서 속성 또는 메서드를 지원하는지 어떻게 알 수 있을까요? 클래스 정의를 살펴 봅니다.

클래스 정의 검색

WMI에 있는 모든 것처럼, 관리 리소스의 클래스 정의를 검색할 수 있는 방법은 다양합니다. 우리가 과장해서 말하는 것일 수도 있겠지만, 다양한 방식으로 모든 사용자 인터페이스 기본 설정에 대한 해결책이 존재한다고 말할 수 있습니다. 텍스트 파일을 알아보고자 한다면 MOF 파일을 잘라봅니다. 명령줄을 원한다면 WMI 명령줄 도구 wmic.exe (Windows XP 전용)를 사용하십시오. 그래픽 도구에서 시간을 보내고 싶다면 WMI Tester (wbemtest.exe) 또는 CIM Studio를 사용하십시오. 그렇지 않고 우리 방식이 마음에 든다면 WMI 스크립팅 라이브러리를 찾아 보십시오.

WMI 스크립팅 라이브러리를 사용하여 세 가지 방법으로 관리 리소스 클래스 정의를 검색할 수 있습니다.

1. SWbemObject Qualifiers_, Properties_ 및 Methods_ 속성을 사용하여 클래스 정보를 검색할 수 있습니다.
2. SWbemObject GetObjectText_ 메서드를 사용하여 MOF 구문 형식의 클래스 정의를 검색할 수 있습니다.
3. SWbemObjectEx GetText_ 메서드를 사용하여 XML 형식(Windows XP 및 Windows Server 2003 전용)의 클래스 정의를 검색할 수 있습니다.

각 스크립팅 솔루션을 살펴본 다음 업무를 끝내십시오.

SWbemObject Properties_, Methods_ 및 Qualifiers_ 사용

목록 9, 10, 11에는 WMI 스크립팅 라이브러리 SWbemObject의 Properties_, Methods_ 및 Qualifiers_ 속성을 사용하여 Win32_Service 클래스에 대한 정보를 검색하는 방법이 있습니다. 세 가지 스크립트가 모두 같은 기본적인 방법을 사용하고 있으므로 목록 9를 살펴본 다음 목록 10과 11의 차이점을 지적해 보십시오.

목록 9는 strComputer, strNameSpace, strClass 세 가지 변수를 초기화함으로써 시작합니다. strComputer에 할당된 값은 대상 WMI 사용 가능 컴퓨터입니다. strNameSpace에 할당된 값은 연결할 네임스페이스입니다. 그리고 strClass에 할당된 값은 속성이 검색되고 표시될 대상 네임스페이스 안에 있는 클래스의 이름입니다. 세 개의 값을 여러 개의 변수로 나누면 쉽게 다른 컴퓨터, 네임스페이스, 클래스에 대한 스크립트를 다시 사용할 수 있습니다. 사실 WSH(Windows Script Host) 인수 컬렉션을 사용하여 목록 9를 쉽게 명령줄 스크립트로 바꿀 수 있습니다.

그 다음 스크립트는 VBScript의 GetObject 함수를 사용하여 대상 컴퓨터의 WMI 서비스에 연결합니다. GetObject에 전달된 연결 문자열에 대해 다른 점이 있습니까? 대상 네임스페이스를 지정하는 것 이외에 클래스 이름도 지정되는데, 이로 인해 GetObject 및 WMI 스크립팅 라이브러리가 반환하는 것이 달라집니다. 이전의 모든 스크립트에서처럼 SWbemServices 개체에 대한 참조를 반환하지 않고 GetObject는 대상 클래스를 나타내는 SWbemObject에 대한 참조를 반환합니다. 그 이유는 무엇일까요? 해답은 개체 경로라는 것에 있습니다. 3부에서 개체 경로에 대해서 자세하게 다루겠지만, 목록 9, 10, 11(그리고 부록 목록 C)의 내용이 이해될 수 있도록 여기에서 간단히 설명하겠습니다.

모든 WMI 클래스와 WMI 관리 리소스의 모든 인스턴스에는 개체 경로가 있습니다. 개체 경로를 파일의 정규화된 경로의 WMI 버전으로 생각하면 됩니다. 모든 파일에는 장치 이름, 0개 이상의 디렉터리 이름, 파일 이름 순으로 이루어진 정규화된 경로가 있습니다. 마찬가지로 모든 클래스와 관리 리소스에는 아래와 같이 WMI 사용 가능 컴퓨터 이름, CIM 네임스페이스, 관리 리소스의 클래스 이름, 클래스의 키 속성 및 키 속성의 값 순으로 이루어진 개체 경로가 있습니다. 대괄호([])는 개체 경로의 네 가지 허용 가능한 부분을 구분할 뿐이며, 개체 경로의 일부가 아닙니다.

[\\ComputerName][\Namespace][:ClassName][.KeyProperty='Value'] 

GetObject에 전달된 연결 문자열에서 개체 경로의 일부 또는 전부를 사용할 때(즉, 지금까지 우리가 해 온 방식대로) 여러분이 사용하는 개체 경로는 GetObject 및 WMI 스크립팅 라이브러리에서 반환한 참조 유형을 결정합니다. 예를 들어 개체 경로의 컴퓨터 이름 부분만 포함시키면 기본 네임스페이스에 연결된 SWbemServices 개체 참조를 얻게 됩니다. 컴퓨터 이름 및/또는 네임스페이스를 포함하면 SWbemServices 개체에 대한 참조를 얻게 됩니다. 컴퓨터 이름, 네임스페이스 및 클래스 이름을 포함하면 클래스를 나타내는 SWbemObject에 대한 참조를 얻게 됩니다. 그리고 네 부분 모두를 포함하면 클래스, 키 및 값으로 식별되는 관리 리소스 인스턴스를 나타내는 SWbemObject를 얻게 됩니다. 이에 대해서는 3부에서 자세하게 다룹니다. 지금은 목록 9의 objClass가 Win32_Service 클래스를 나타내는 SWbemObject에 대한 참조라는 것을 이해해 두십시오.

나머지 스크립트는 간단한 편입니다. 속성이 표시될 클래스 이름을 식별하는 단순 헤더를 반향시키고 나면, 스크립트는 GetObject에서 반환한 SWbemObject 참조(objClass)를 사용하여 SWbemObject Properties_ 속성(objClass.Properties_)에 액세스합니다. SWbemObject Properties_속성은 클래스에 대한 속성 컬렉션인 SWbemPropertySet을 참조합니다. SWbemPropertySet 컬렉션에 있는 각각의 속성은 각 속성의 이름을 읽고 반향시키는 데 사용되는 SWbemProperty(objClassProperty) 개체입니다.

요약하자면, For Each 루프는 클래스의 SWbemPropertySet 컬렉션을 나열하고(SWbemObject Properties_ 속성을 통해) SWbemPropertySet 컬렉션에 있는 각 SWbemProperty에 대한 Name 속성을 반향시킵니다.

목록 9. SWbemObject properties_를 사용하여 Win32_Service 속성 검색

strComputer = "."
strNameSpace = "root\cimv2"
strClass = "Win32_Service"

Set objClass = GetObject("winmgmts:\\" & strComputer & _
                         "\" & strNameSpace & ":" & strClass)

WScript.Echo strClass & " 클래스 속성"
WScript.Echo "------------------------------"

For Each objClassProperty In objClass.Properties_
    WScript.Echo objClassProperty.Name
Next 

그림 9에는 Win32_Service 클래스로 정의되거나 상속된 25개의 속성 이름이 나타납니다.

그림 9. GetProperties.vbs 출력

목록 10은 한 가지 주된 예외를 제외하면 목록 9와 같습니다. For Each 루프는 클래스의 SWbemMethodSet 컬렉션을 열거하고(SWbemObject Methods_ 속성을 통해) SWbemMethodSet 컬렉션에 있는 각 SWbemMethod(objClassMethod)에 대한 Name 속성을 반향시킵니다.

목록 10. SWbemObject methods_를 사용하여 Win32_Service 메서드 검색

strComputer = "."
strNameSpace = "root\cimv2"
strClass = "Win32_Service"

Set objClass = GetObject("winmgmts:\\" & strComputer & _
                         "\" & strNameSpace & ":" & strClass)

WScript.Echo strClass & " 클래스 메서드"
WScript.Echo "---------------------------"

For Each objClassMethod In objClass.Methods_
    WScript.Echo objClassMethod.Name
Next 

그림 10에는 Win32_Service 클래스로 정의되거나 상속된 10개의 메서드 이름이 나타납니다.

그림 10. GetMethods.vbs 출력

목록 11은 세 가지 예외를 제외하고는 목록 9 및 10과 동일합니다.

1. For Each 루프는 클래스의 SWbemQualifierSet 컬렉션을 나열하고(SWbemObject Qualifiers_ 속성을 통해) SWbemQualifierSet 컬렉션에 있는 각 SWbemQualifier(objClassQualifier)에 대한 Name 속성을 반향시킵니다.
2. 클래스 한정자는 클래스 정의의 일부이고 한정자는 값을 갖기 때문에, 목록 11 역시 SWbemQualifierSet 컬렉션에 있는 각 SWbemQualifier(objClassQualifier)에 대한 Value 속성을 검색하여 반향시킵니다.
3. 한정자는 배열에 저장된 값을 여러 개 가질 수 있기 때문에, 목록 11은 한정자의 값을 읽기 전에 이 값을 설명해야 합니다. 그렇게 하지 않으면 스크립트가 배열 기반 한정자를 스칼라 변수로 읽는 경우 런타임 오류가 발생합니다. Win32_NTLogEvent 클래스의 Privileges 한정자는 배열 기반 한정자의 예입니다.

목록 11. SWbemObject qualifiers_를 사용하여 Win32_Service 클래스 한정자 검색

strComputer = "."
strNameSpace = "root\cimv2"
strClass = "Win32_Service"

Set objClass = GetObject("winmgmts:\\" & strComputer & _
                         "\" & strNameSpace & ":" & strClass)

WScript.Echo strClass & " 클래스 한정자"
WScript.Echo "------------------------------"

For Each objClassQualifier In objClass.Qualifiers_
    If VarType(objClassQualifier.Value) = (vbVariant + vbArray) Then
        strQualifier = objClassQualifier.Name & " = " & _
                       Join(objClassQualifier.Value, ",")
    Else
        strQualifier = objClassQualifier.Name & " = " & _
                       objClassQualifier.Value
    End If
    WScript.Echo strQualifier
    strQualifier = ""
Next 

그림 11에는 Win32_Service 클래스에서 정의하거나 상속한 5개의 클래스 한정자의 이름 및 값이 나타납니다.

그림 11. GetClassQualifiers.vbs 출력

여러분도 눈치채셨겠지만 목록 9와 10에는 속성 및 메서드 한정자가 나타나지 않습니다. 솔직히 말하면, 의도적으로 쉽게 설명할 수 있는 크기로 스크립트를 유지하려 했습니다. 희소식은 전체 클래스 한정자, 속성, 속성 한정자, 메서드 및 메서드 한정자 스크립트를 칼럼 끝에 포함시켰다는 것입니다(부록 목록 C 참조). 잘 한 일 아닙니까?

그리고 명확하지는 않지만 여러분은 목록 6(GetAllNamespaces.vbs 스크립트) 및 목록 8(GetClasses.vbs 스크립트)과 목록 9, 10, 11을 결합하여 CIM에 정의된 모든 클래스에 대한 속성, 메서드 및 한정자를 검색할 수 있습니다. findstr.exe 명령으로 만들어진 스크립트 및 솔루션을 사용하여 CIM에 정의된 클래스, 속성, 메서드, 또는 한정자를 검색할 수 있습니다.

SWbemObject GetObjectText_ 사용

클래스가 정의되는 MOF 파일에서 직접 관리 리소스 클래스 정의를 검색할 수 있다고 앞서 말씀드렸습니다. 그 방법은 다음과 같습니다. 예를 들어 Win32_Service 클래스를 찾으려고 하는 경우 %SystemRoot%\system32\wbem\cimwin32.mof 파일을 살펴보십시오. 그러나 MOF 파일을 사용하는 데에는 대가가 따릅니다. 관리 리소스의 클래스 계층 구조의 모든 클래스를 살펴보고 관리 리소스에 대한 전체 청사진을 구해야 합니다.

예를 들어, Win32_Service를 찾으려고 한다고 가정합시다. 그림 1에서 볼 수 있듯이, Win32_Service 클래스 계층 구조에 있는 5개의 클래스를 모두 살펴보고 전체를 이해해야 합니다. 이것은 WMI Tester(wbemtest.exe)의 Show MOF 단추(그림 7 참조)를 사용하는 경우에도 해당됩니다. 클래스의 MOF 표현을 쉽게 파악하려면 목록 12에서처럼 WMI 스크립팅 라이브러리의 SWbemObject GetObjectText_ 메서드를 사용합니다.

목록 9, 10, 11과는 달리, 목록 12는 SWbemServices Get 메서드를 사용하여 GetObject가 아닌 클래스를 검색합니다. wbemFlagUseAmendedQuailifiers 플래그를 사용할 수 있도록 SWbemServices Get 메서드를 사용해야 합니다. wbemFlagUseAmendedQuailifiers 플래그를 활성화하면 WMI은 로컬 정의가 아니라 전체 관리 리소스 청사진(클래스 정의)를 반환합니다.

wbemFlagUseAmendedQualifiers 플래그를 사용하면 당연히 두 번째 이점이 있습니다. 또한 클래스 설명과 클래스의 속성, 메서드 및 한정자 각각에 대한 설명을 얻을 수도 있습니다. 일반적으로 클래스, 속성, 메서드 및 한정자 설명은 지역화용으로 별도의 MOF 파일에 정의됩니다. 예를 들어 Win32_Service 클래스의 언어 중립적인 부분은 cimwin32.mof에 정의됩니다. 설명 정보가 들어 있는 Win32_Service 클래스의 언어 관련 부분은 cimwin32.mfl에 정의됩니다. 언어 관련, 또는 지역화된 MOF 파일에는 일반적으로 .mof가 아닌 .mfl 확장명이 붙습니다.

SWbemServices Get 메서드는 대상 클래스를 나타내는 SWbemObject(objClass)에 대한 참조를 반환하며, 이 클래스는 SWbemObject GetObjectText_ 메서드를 호출할 때 사용됩니다. GetObjectText_ 메서드는 클래스에 대한 MOF 표현을 반환합니다. wbemFlagUseAmendedQualifiers 플래그를 활성화하지 않고 GetObjectText_를 사용했다면 해당 메서드는 Win32_Service에서 정의한 속성, 메서드 및 한정자만을 반환하며, 상속된 속성 및 메서드는 생략됩니다.

목록 12. SWbemObject GetObjectText_를 사용하여 Win32_Service 클래스의 MOF 표현 검색

strComputer = "."
strNameSpace = "root\cimv2"
strClass = "Win32_Service"

Const wbemFlagUseAmendedQualifiers = &h20000

Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\" & strNameSpace)
Set objClass = objWMIService.Get(strClass, wbemFlagUseAmendedQualifiers)
strMOF = objClass.GetObjectText_

WScript.Echo strMOF 

GetObjectText_를 사용할 때 주의해야 하지만, 메서드에서 반환한 MOF 구문에 있는 상속된 한정자에 대한 정보는 존재하지 않습니다. 부모 클래스에 있는 속성에서 Key 한정자가 정의될 때 GetObjectText_를 사용하여 클래스의 Key 속성을 결정하면 문제가 될 수 있습니다.

SWbemObjectEx GetText_ 사용

Windows XP 및 Windows Server 2003 모두에 관리 리소스 클래스 정의의 XML 표현 검색에 사용할 수 있는 GetText_라는 새로운 메서드가 있습니다.

GetText_의 사용법은 한 가지 예외를 제외하면 GetObjectText_와 같습니다. GetText_ 메서드에 전달되는 세 가지 매개 변수가 바로 그 예외입니다.

첫 번째 매개 변수는 필수적이며, 결과 XML 형식을 식별합니다. 이 매개 변수는 현재 WMI WbemObjectTextFormatEnum에서 정의하는 두 가지 값 wbemObjectTextFormatCIMDTD20(값: 1) 또는 wbemObjectTextFormatWMIDTD20(값: 2) 중 하나가 될 수 있습니다. 2라는 값(wbemObjectTextFormatWMIDTD20)은 Distributed Management Task Force CIM DTD(Document Type Definition) 버전 2.0의 확장 WMI 버전에 따라서 결과 XML을 포맷하도록 GetText_에 지시합니다.

두 번째 매개 변수는 선택적이며, 현재 작업 플래그용으로 예약되어 있습니다. 이 매개 변수는 0으로 설정되어야 합니다.

세 번째 매개 변수(또는 선택적) colNamedValueSet는 GetText_에 대한 특별한 명령을 제공하는 SWbemNamedValueSet 컬렉션입니다. GetText_는 다음을 수행합니다.

• 로컬로 정의된 속성 및 메서드뿐 아니라 모든 속성 및 메서드를 검색하고 인코딩합니다.
• 결과로 만들어진 XML의 메서드 식별자, 클래스 식별자, 속성 식별자가 포함됩니다.
• 결과로 만들어진 XML의 시스템 속성이 포함됩니다.
• 모든 속성 및 메서드에 대한 클래스 원본이 포함됩니다.

목록 13. SWbemObjectEx GetText_를 사용하여 Win32_Service 클래스(Windows XP 및 Windows .NET 전용)의 XML 표현 검색

strComputer = "."
strNameSpace = "root\cimv2"
strClass = "Win32_Service"

Const wbemFlagUseAmendedQualifiers = &h20000
Const wbemObjectTextFormatWMIDTD20 = 2

Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\" & strNameSpace)
Set objClass = objWMIService.Get(strClass, wbemFlagUseAmendedQualifiers)

Set colNamedValueSet = CreateObject("Wbemscripting.SWbemNamedValueSet")
colNamedValueSet.Add "LocalOnly", False
colNamedValueSet.Add "IncludeQualifiers", True
colNamedValueSet.Add "ExcludeSystemProperties", False
colNamedValueSet.add "IncludeClassOrigin", True

strXML = objClass.GetText_(wbemObjectTextFormatWMIDTD20, 0, colNamedValueSet)

WScript.Echo strXML 

목록 13을 성공적으로 실행하려면, 스크립트를 복사하여 원하는 텍스트 편집기에 붙여넣은 후 .vbs 확장명 (예: GetXML.vbs)으로 스크립트를 저장하고 아래에 있는 명령줄을 사용하여 스크립트를 실행합니다.

C:\Scripts> cscript //nologo GetXML.vbs >Win32_Service.xml 

그림 12에는 Microsoft Internet Explorer를 사용한 결과 만들어진 결과 XML 파일 Win32_Service.xml이 나타납니다.

그림 12. GetXML.vbs 출력

결론

WMI에 대해서 혼란스럽거나 어렵거나 버거운 부분이 있다면 WMI를 통해 알려진 수많은 데이터를 처리하는 중일 것입니다. 우리는 WMI 관리 리소스 클래스 정의를 효과적으로 찾아 해석하는 데 필요한 지식과 도구를 여러분에게 제공했습니다. 물론 여러분이 그에 대해 가장 잘 평가를 내릴 수 있습니다. 그렇기에 혹시 우리가 설명을 제대로 못한 부분이 있다면 알려주십시오. 지루한 내용이 있기는 하지만, WMI 스크립팅 라이브러리에 대해 자세히 다루는 3부에서는 흥미를 느낄 수 있도록 준비해 보십시오. 이제 업무에서 벗어나 이제 여유를 즐겨 보십시오.

잠깐만요! 한 가지 유의할 점이 있습니다. 즉, WMI 개발 팀은 전에 WMI SDK와 함께만 사용할 수 있었던 WMI Tools 가 업데이트되었다는 사실을 알려주도록 우리에게 요청했습니다. 업데이트된 도구(여기에는 WMI CIM Studio, WMI Event Registration, WMI Event Viewer 및 WMI Object Browser가 포함됩니다)는 이제 Windows 2000뿐만 아니라 Windows XP 및 Windows Server 2003과도 호환됩니다. 또한 업데이트된 도구에는 WMI SDK가 포함되어 있지 않으며, 이것은 전체 WMI SDK를 설치하지 않고도 지금 도구를 설치할 수 있음을 의미합니다. 멋지지 않습니까?

부록 스크립트

목록 A. root\cimv2 네임스페이스에 정의된 추상 클래스 형식 나열

strComputer = "."   

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

For Each objClass in colClasses
    For Each objClassQualifier In objClass.Qualifiers_
        If LCase(objClassQualifier.Name) = "abstract" Then
            WScript.Echo objClass.Path_.Class   & ": " & _
                         objClassQualifier.Name & "="  & _
                         objClassQualifier.Value
        End If
    Next
Next  

목록 B. root\cimv2 네임스페이스에 정의된 동적 클래스 형식 나열

strComputer = "."   

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

For Each objClass in colClasses
    For Each objClassQualifier In objClass.Qualifiers_
        If LCase(objClassQualifier.Name) = "dynamic" Then
            WScript.Echo objClass.Path_.Class   & ": " & _
                         objClassQualifier.Name & "="  & _
                         objClassQualifier.Value
        End If
    Next
Next   

목록 C. SWbemObject Qualifiers_, Properties_, 및 Methods_를 사용하여 클래스 한정자, 속성, 속성 한정자, 메서드 및 메서드 한정자 검색

strComputer = "."
strNameSpace = "root\cimv2"
strClass = "Win32_Service"

Set objClass = GetObject("winmgmts:\\" & strComputer & _
                         "\" & strNameSpace & ":" & strClass)

WScript.Echo strClass & " 클래스 한정자"
WScript.Echo "------------------------------"
i = 1
For Each objClassQualifier In objClass.Qualifiers_
    If VarType(objClassQualifier.Value) = (vbVariant + vbArray) Then
        strQualifier = i & "  .  " & objClassQualifier.Name & " = " & _
                                  Join(objClassQualifier.Value, ",")
    Else
        strQualifier = i & "  .  " & objClassQualifier.Name & " = " & _
                                  objClassQualifier.Value
    End If
    WScript.Echo strQualifier
    strQualifier = ""
    i = i + 1
Next

WScript.Echo
WScript.Echo strClass & " 클래스 속성 및 속성 한정자"
WScript.Echo "------------------------------------------------------"
i = 1 : j = 1
For Each objClassProperty In objClass.Properties_
    WScript.Echo i & "  .  " & objClassProperty.Name
    For Each objPropertyQualifier In objClassProperty.Qualifiers_
        If VarType(objPropertyQualifier.Value) = (vbVariant + vbArray) Then
            strQualifier = i & "."   & j & "  .  " & _
                           objPropertyQualifier.Name & " = " & _
                           Join(objPropertyQualifier.Value, ",")
        Else
            strQualifier = i & "."   & j & "  .  " & _
                           objPropertyQualifier.Name & " = " & _
                           objPropertyQualifier.Value
        End If
        WScript.Echo strQualifier
        strQualifier = ""
        j = j + 1
    Next
    WScript.Echo
    i = i + 1 : j = 1
Next

WScript.Echo
WScript.Echo strClass & " 클래스 메서드 및 메서드 한정자"
WScript.Echo "-------------------------------------------------"
i = 1 : j = 1
For Each objClassMethod In objClass.Methods_
    WScript.Echo i & "  .  " & objClassMethod.Name
    For Each objMethodQualifier In objClassMethod.Qualifiers_
        If VarType(objMethodQualifier.Value) = (vbVariant + vbArray) Then
            strQualifier = i & "."   & j & "  .  " & _
                           objMethodQualifier.Name & " = " & _
                           Join(objMethodQualifier.Value, ",")
        Else
            strQualifier = i & "."   & j & "  .  " & _
                           objMethodQualifier.Name & " = " & _
                           objMethodQualifier.Value
        End If
        WScript.Echo strQualifier
        strQualifier = ""
        j = j + 1
    Next
    WScript.Echo
    i = i + 1 : j = 1
Next  

스크립팅 클리닉

Greg Stemp는 오랫동안 전국 최고의 스크립팅 대가 중 한 사람으로, 또한 세계적인 풋볼 코치로 널리 인정받아 왔습니다. 그런데 어떻게 이런 일을 하게 되었냐구요? 그는 "해고"되었습니다. Greg Stemp는 ... 이제 이렇게 말할 수 밖에 없군요. 좋습니다. Greg Stemp는 Microsoft에서 System Administration Scripting Guide의 수석 집필진입니다.

Dean Tsaltas는 노바 스코샤 출신으로 레드먼드에 살고 있습니다. 그는 영어를 유창하게 구사하며, 심지어 친구와 가족들의 액센트도 비웃을 정도로 영어 실력이 뛰어납니다. 그는 할머니와 부모님이 그가 애지중지하는 C-64를 사주고 Compute!' Gazette를 구독하게 해 준 어린 시절에 컴퓨팅을 시작했습니다! 그는 수년간 Microsoft에서 재직중이며, 집과 뱅쿠버에 있는 친구와 가족에 대해 다음과 같은 메시지를 전하고 싶어합니다. "아직 Bill을 만나지 못했어요!"

Bob Wells는 관심을 갖고 있는 사람이면 누구에게나 스크립팅의 가치를 역설합니다. Bob이 키우는 두 마리 닥스훈트도 보통 사람보다 스크립팅에 대해 더 많이 알고 있다는 소문이 있습니다. 여가 시간에 Bob은 System Administration Scripting Guide에 기고합니다.

Ethan Wilansky는 많은 시간을 저술 및 컨설팅 활동에 보냅니다. 그리고 스크립팅, 요가, 원예 및 가정일에 열심입니다. 현재는 쓰레기를 버리고 설겆이를 하는 스크립트를 만드는 일에 전념하고 있습니다.

Greg Stemp, Dean Tsaltas, Bob Wells
Microsoft Corporation

Ethan Wilansky
Network Design Group

2003년 1월 23일

요약: WMI 스크립팅 라이브러리를 정의하고 이를 사용하여 WMI 관리 리소스에 액세스하고 관리하는 방법에 대해 설명합니다. 관리 리소스 인스턴스의 생성, 삭제 및 검색 등의 작업을 위해 WMI 스크립팅 라이브러리를 사용하여 만들 수 있는 7가지 기본 스크립트 유형을 살펴봅니다(22페이지/인쇄 페이지 기준).

스크립팅 입문을 기다리신 독자 여러분! 오랜만에 인사드립니다. Microsoft Windows 2000 Scripting Guide(나중에 자세하게 다룸)를 완성하는 중이었다는 등의 구구한 변명을 늘어놓는지 않겠습니다. 그럼 바로 시작해 볼까요? 이 문서에서는 지난 번 WMI 스크립팅 입문 과정에서 다루지 못했던 WMI 스크립팅 퍼즐의 나머지 조각, 즉 WMI 스크립팅 라이브러리에 대해 검토해 보겠습니다.

자세히 살펴 보기 전에 지금까지 다룬 내용을 잠시 복습해 봅시다. WMI 스크립팅 입문: 1부에서는 WMI 스크립팅과 관련된 WMI의 아키텍처 및 주요 구성 요소를 다루었습니다. WMI 스크립팅 입문: 2부에서는 CIM(Common Information Model), 즉 WMI 관리 리소스용 청사진(클래스 정의)을 갖고 있는 리포지토리에 대해서 설명했습니다. "이 페이지 등급" 검색 횟수를 통해 여러분 중 많은 사람이 2부를 읽지 않고 건너뛰었다는 것을 알고 있지만 여기에서는 여러분이 2부의 내용을 알고 있다고 가정합니다. 만일 모른다면 해당 자료를 직접 찾아보시기 바랍니다.

정의된 WMI 스크립팅 라이브러리

WMI 스크립팅 라이브러리란 무엇일까요? 이 질문에 답하기 위해서 잠시 유추해보겠습니다. 컴퓨터의 미디어 플레이어나 스테레오 시스템에 대해 잠시 생각해 봅시다. 모든 스테레오가 공통적으로 가지고 있는 것은 무엇입니까? 모두 볼륨 컨트롤, 고음 및 저음 컨트롤, 튜너(라디오), 이퀄라이저가 있습니다. 베토벤, 레드 제플린, 아트 오브 노이즈 등 어떤 음악을 듣건 간에 컨트롤이 작동하는 방식은 항상 똑같습니다.

완전히 똑같다고는 할 수 없지만 재미있게 비교해 보자면 WMI 스크립팅 라이브러리는 스테레오에 있는 컨트롤과 비슷하다고 할 수 있습니다. 즉, WMI 스크립팅 라이브러리는 WMI 관리 리소스에 액세스하고 관리할 수 있도록 해주는 일관성 있는 컨트롤 집합을 자동화 개체 형태로 제공합니다. 컴퓨터, 이벤트 로그, 운영 체제, 프로세스, 서비스를 관리하고 있는지 또는 원하는 리소스를 선택하는지는 문제가 되지 않습니다. WMI 스크립팅 라이브러리에 있는 개체는 항상 동일하게 작동합니다.

WMI 스크립팅 라이브러리의 자동화 개체가 제공하는 일관성은 WMI 스크립팅 라이브러리를 사용하여 실행할 수 있는 일련의 작업으로 가장 잘 전달됩니다. WMI 스크립팅 라이브러리를 사용하여 다음 7가지 기본 스크립트 유형을 만들 수 있습니다.

1. WMI 관리 리소스의 인스턴스를 검색할 수 있습니다.
2. WMI 관리 리소스의 속성을 읽을 수 있습니다.
3. WMI 관리 리소스의 속성을 수정할 수 있습니다.
4. WMI 관리 리소스의 메서드를 호출할 수 있습니다.
5. WMI 관리 리소스의 새 인스턴스를 만들 수 있습니다.
6. WMI 관리 리소스의 인스턴스를 삭제할 수 있습니다.
7. WMI 관리 리소스의 생성, 수정 및/또는 삭제를 모니터링할 이벤트를 구독할 수 있습니다.

7가지 기본 스크립트 유형을 스크립트 템플릿으로 생각하면 됩니다. 그리고 볼륨 컨트롤이 CD, 카세트, 8트랙 테이프 또는 .wma 파일의 소리 크기를 조정하는 것처럼, WMI 스크립트 템플릿을 사용하여 WMI 관리 리소스를 관리할 수 있습니다. 한 가지 WMI 관리 리소스 유형을 관리할 수 있을 정도로 템플릿에 대해서 잘 이해하고 있으면 동일한 템플릿을 조정하여 다른 수백개의 WMI 관리 리소스를 쉽게 관리할 수 있습니다.

WMI 스크립팅 라이브러리 개체 모델

WMI 스크립팅 라이브러리를 만들었으므로 이제 전체 WMI 인프라를 제어할 수 있습니다. 섀시를 열고 안을 살펴 보십시오. 이 시리즈의 1부에 있는 그림 3은 WMI 스크립팅 라이브러리가 %SystemRoot%\system32\wbem 디렉터리에 있는 wbemdisp.dll이라는 단일 자동화 구성 요소로 구현되는 것을 보여주었습니다.

WMI 스크립팅 라이브러리는 24개의 자동화 개체(Windows 2000 및 이전 버전에서는 19개)로 구성되며, 이 중 21개는 그림 1의 WMI 스크립팅 라이브러리 개체 모델 다이어그램에 나타나 있습니다. 이제 24개의 모든 개체에 대해서 자세히 배우기 전에 먼저 해서는 안될 일을 알아 봅시다. 사실, 그림 1에 있는 개체 중 두 세 개를 기본적으로 이해하고 있으면 앞에서 나열한 7개의 스크립트 템플릿 중 6개를 만들 수 있습니다. 그렇다면 이 개체는 무엇일까요? 너무 서두르지 말고 침착하게 생각해 봅시다.

Microsoft Windows XP 및 Windows Server 2003 버전의 wbemdisp.dll에 있는 24개의 자동화 개체 이외에 스크립팅 라이브러리에는 13개의 열거가 들어 있습니다. 열거는 관련 상수 그룹에 붙인 상상의 이름일 뿐입니다. 상수 그룹은 WMI SDK에 잘 설명되어 있으므로 여기에서는 다루지 않겠습니다. WMI 스크립팅 상수에 대한 자세한 내용은 WMI SDK의 Scripting API Constants  를 참조하십시오.

여러 방법으로 WMI 스크립팅 라이브러리의 자동화 개체와 ADSI에서 제공하는 핵심 인터페이스를 비교할 수 있습니다. 이것은 무슨 뜻일까요? ADSI 핵심 인터페이스(예: IAD와 IADsContainer)는 개체의 클래스 및 특성에 상관없이 Active Directory의 스크립팅 개체에 일관된 접근법을 제공합니다. 마찬가지로, WMI 스크립팅 라이브러리의 자동화 개체는 WMI 관리 리소스에 일관된 스크립팅 모델을 제공합니다.

WMI 스크립팅 라이브러리(wbemdisp.dll)의 자동화 개체와 CIM 리포지토리(objects.data)에 있는 관리 리소스 클래스 정의간의 관계를 이해하는 것이 중요합니다. 2부에서 설명했듯이 관리 리소스 클래스 정의는 WMI를 통해 제공되는 컴퓨터 리소스에 대한 청사진입니다. 청사진은 관리될 수 있는 리소스를 정의할 뿐 아니라 각 관리 리소스에 고유한 메서드 및 속성을 정의합니다.

다른 한편으로 WMI 스크립팅 라이브러리는 일반 용도로 사용할 수 있는 자동화 개체 집합을 제공하여 WMI를 인증하고 연결한 후 WMI 관리 리소스의 인스턴스에 액세스합니다. 일단 WMI 스크립팅 라이브러리를 사용하여 WMI 관리 리소스의 인스턴스를 얻으면 관리 리소스 클래스 정의에서 정의한 메서드 및 속성을 마치 스크립팅 라이브러리 자체의 일부였던 것처럼 액세스할 수 있습니다.

그림 1. WMI 스크립팅 라이브러리 개체 모델인 wbemdisp.dll

WMI 스크립팅 라이브러리 개체 모델 해석

그림 1은 처음 볼 때는 잘 이해되지 않지만 이 WMI 스크립팅 라이브러리 개체 모델을 통해 WMI 스크립팅 작업 방법 메커니즘을 잘 이해할 수 있습니다. 그림 1에서 볼 수 있는 줄은 원래 개체의 메서드를 호출하거나 속성을 액세스하여 얻은 개체를 가리킵니다. 예를 들어 SWbemLocator ConnectServer 메서드를 호출하면 SWbemServices 개체가 반환됩니다. SWbemServices ExecNotificationQuery 메서드를 호출하면 SWbemEventSource 개체가 반환됩니다. 다른 한편으로, SWbemServices ExecQuery 또는 InstancesOf 메서드를 호출하면 SWbemObjectSet 컬렉션이 반환됩니다. 그리고 SWbemServices Get 메서드를 호출하면 SWbemObject가 반환됩니다.

이 시리즈의 1부 및 2부에 있는 WMI 스크립트와 개체 모델을 비교하여 어떻게 작동하는지 살펴 보십시오. 각 스크립트는 대부분의 WMI 스크립트에 공통되는 세 가지 기본 단계를 실행했습니다.

1. 대상 컴퓨터에 있는 WMI 서비스에 연결하여 각 스크립트를 시작했습니다. 이 스크립트에서는 Microsoft Visual Basic Scripting Edition(VBScript) GetObject 함수와 WMI 모니커인 "winmgmts:" 다음에 대상 컴퓨터 및 네임스페이스에 대한 WMI 개체 경로를 지정한 WMI 연결 문자열을 함께 사용했습니다.

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

   이런 식으로 WMI에 연결하면 그림 1에 있는 SWbemServices 개체에 대한 참조가 반환됩니다. 일단 SWbemServices 개체에 대한 참조를 얻으면 SwbemServices 메서드 중 하나를 호출할 수 있습니다. 주로 호출할 수 있는 SWbemServices 메서드는 생성 중인 WMI 스크립트 유형에 따라 달라집니다.

2. 그런 다음 각 스크립트에서는 SWbemServices InstancesOf 메서드를 사용하여 WMI 관리 리소스 인스턴스를 검색했습니다.

   Set colSWbemObjectSet = objSWbemServices.InstancesOf("Win32_Service")
   

   InstancesOf는 항상 SWbemObjectSet 컬렉션을 반환합니다. 그림 1의 SWbemServices와 SWbemObjectSet 개체 사이에 줄이 표시되어 있듯이, SWbemObjectSet는 SWbemServices가 반환할 수 있는 세 가지 WMI 스크립팅 라이브러리 중 하나입니다.

3. 마지막으로 각 스크립트에서는 SWbemObjectSet의 인스턴스를 열거하여 WMI 관리 리소스 속성에 액세스했습니다.

   For Each objSWbemObject In colSWbemObjectSet
       WScript.Echo "이름: " & objSWbemObject.Name
   Next
   

   그림 1에 나타나 있듯이, SWbemObjectSet 컬렉션의 각 관리 리소스 인스턴스는 SWbemObject로 표현됩니다.

WMI 스크립팅 라이브러리에 있는 24개의 자동화 개체 중에서 가장 중요한 세 가지 개체(즉, 먼저 배워야 하는 세 가지 개체)는 SWbemServices, SWbemObjectSet, SWbemObject입니다. 그 이유는 무엇일까요? SWbemServices, SWbemObjectSet 및 SWbemObject는 거의 모든 WMI 스크립트에 중요한 요소이기 때문입니다. 사실 ADSI 유추를 다시 살펴 보면 SWbemServices, SWbemObjectSet 및 SWbemObject가 WMI 스크립팅과 관련이 있고 IADs 및 IADsContainer는 ADSI 스크립팅과 관련이 있습니다. (팁: ADSI 스크립팅을 조금이라도 해보지 않은 분에게 알려 줄 한 가지 팁이 있습니다. ADSI 라이브러리에서 제공하는 60개의 인터페이스 중에서 IADs 및 IADsContainer를 가장 먼저 배우는 것이 좋습니다.)

SWbemServices는 로컬 또는 원격 컴퓨터의 WMI 네임스페이스에 대한 인증된 연결을 나타내는 개체입니다. 또한 SWBemServices는 모든 WMI 스크립트에서 중요한 역할을 합니다. 예를 들어 관리 리소스의 모든 인스턴스를 검색하려면 SWbemServices InstancesOf 메서드를 사용해야 합니다. 마찬가지로 WQL(WMI Query Language) 쿼리와 함께 SWbemServices ExecQuery 메서드를 사용하여 모든 관리 리소스 인스턴스 또는 그 하위 집합을 검색할 수 있습니다. 관리 환경에서 변경을 나타내는 이벤트를 구독하려면 SWbemServices ExecNotificationQuery 메서드를 사용합니다.

SWbemObjectSet는 0개 이상의 SWbemObject 개체로 구성된 컬렉션입니다. 왜 0일까요? 컴퓨터는 0개의 인스턴스, 즉 테이프 드라이브(Win32_TapeDrive 모델)를 가질 수 있기 때문입니다. SWbemObjectSet에서 각 SWbemObject는 다음 중 하나를 나타낼 수 있습니다.

1. WMI 관리 리소스 인스턴스
2. 클래스 정의 인스턴스

SWbemObject는 관리 중인 리소스처럼 가장하는 다중 ID 개체입니다. 예를 들어 Win32_Process 관리 리소스를 검색하는 경우 SWbemObject는 그림 2의 왼쪽에 보여지는 것처럼 Win32_Process 클래스 정의 이후에 모델화된 ID를 사용합니다. 반면 Win32_Service 관리 리소스 인스턴스를 검색하는 경우에는 SWbemObject는 그림 2의 오른쪽에 보여지는 것처럼 Win32_Service 클래스 이후에 모델화된 ID를 사용합니다.

그림 2. Win32_Process 및 Win32_Service로 가장한 SWbemObject

그림 2를 자세히 살펴 보면 SWbemObject가 두 가지 다른 메서드 및 속성 집합을 보여주고 있는 것을 알 수 있습니다. 밑줄로 끝나는 이름을 가진 위쪽 집합은 SWbemObject에 속하고 wbemdisp.dll에 존재합니다. 밑줄은 관리 리소스의 클래스 정의에서 정의한 메서드 및 속성과의 이름 충돌을 막기 위해 사용됩니다.

아래 메서드 및 속성 집합은 SWbemObject에 속하지 않습니다. 이 집합은 CIM에 있는 관리 리소스의 클래스 정의에서 정의합니다. 관리 리소스의 인스턴스를 검색할 때 SWbemObject는 관리 리소스의 클래스 정의에서 정의한 메서드 및 속성에 동적으로 바인딩합니다. SWbemObject를 사용하면 마치 SWbemObject의 일부였던 것처럼 관리 리소스의 클래스에 정의된 메소드를 호출하고 속성에 액세스할 수 있습니다. CIM에 정의된 관리 리소스로 몰핑하는 SWBemObject의 기능은 WMI 스크립팅을 매우 직관적이게 해 줍니다. 인스턴스를 연결하고 검색하는 방법을 알게 되면 이제 SWbemObject만 알면 됩니다.

자. 그러면 WMI 스크립팅 라이브러리 개체 모델에서 무엇을 알 수 있을까요? VBScript(또는 WSH) GetObject 함수와 함께 WMI 모니커(winmgmts:)와 WMI 개체 경로(예: "[\\ComputerName][\Namespace][:ClassName][.KeyProperty='Value']")를 사용하여 SWbemServices 및 SWbemObject를 직접 만들 수 있습니다. 반면 SWbemLocator, SWbemLastError, SWbemObjectPath, SWbemNamedValueSet, SWbemSink, SWbemDateTime 및 SWbemRefresher 개체는 VBScript(또는 WSH) CreateObject 함수를 사용하여 만들어집니다. 나머지 개체는 GetObject 또는 CreateObject를 사용하여 만들 수 없습니다. 대신 이 개체는 메서드를 호출하거나 속성에 액세스하여 얻을 수 있습니다.

또한 개체의 오른쪽 또는 바로 아래에 있는 보안 설명선 아이콘으로 표시되어 있듯이 WMI 스크립팅 라이브러리의 7개 개체는 SWbemSecurity 개체를 노출합니다.

특정 스크립팅 라이브러리 개체, 메서드 또는 속성에 대한 자세한 내용은 WMI SDK Documentation  의 Scripting API for WMI  를 참조하십시오. WMI 스크립팅 라이브러리의 기본 역학을 이해하려면 앞에서 나열한 WMI 스크립트 템플릿을 살펴 보십시오. WMI 스크립트 템플릿을 살펴 보기 전에 변수 명명 규칙에 대해 잠시 살펴 보겠습니다.

변수 명명 규칙에 대한 정보

다음 예제 스크립트에서 각 WMI 자동화 개체를 참조하는 데 사용된 변수 이름은 일관된 명명 규칙을 따릅니다. 각 변수는 WMI 스크립팅 라이브러리에 있는 자동화 개체 이름에 따라 명명되며 앞에 "obj"(개체 참조) 또는 "col"(컬렉션 개체 참조)이 붙습니다. 예를 들어 SWbemServices 개체를 참조하는 변수는 objSWbemServices로 명명됩니다. SWbemObject를 참조하는 변수는 objSWbemObject로 명명됩니다. SWbemObjectSet를 참조하는 변수는 colSWbemObjectSet로 명명됩니다.

이런 명명 규칙은 왜 중요할까요? 중요하지 않다고 말할 사람도 물론 있을 것입니다. 그러나 이런 명명 방법을 사용하면 WMI 스크립트에서 각기 다르게 작동하는 WMI 개체 유형을 이해하는 데 도움이 됩니다. 도움이 되면 좋고 도움이 안되는 경우에는 무시하면 됩니다. 염두에 두어야 할 다른 중요한 점은 개체 참조 변수 이름은 여러분이 좋아하는 어떤 이름이든 사용할 수 있다는 것입니다. foo and bar 또는 dog and cat과 같은 변수 이름을 선호한다면 사용해도 됩니다. SWbemServices 개체에 대한 참조에 objSWbemServices라고 명명해야 한다는 필수 조항은 없습니다. 이 방법은 단지 저희가 사용하는 방법일 뿐입니다.

WMI 스크립트 템플릿에 대한 가이드

WMI는 배우기도 아주 어렵지만 사용하기는 훨씬 더 어렵다고 알려져 있습니다. 여러 면에서 볼 때 이러한 명성은 WMI가 실제로 어려워서라기 보다는 그 범위와 내용이 매우 방대하기 때문에 얻어진 것입니다. WMI를 사용하여 컴퓨터 하드웨어, 컴퓨터 소프트웨어 및 하드웨어와 소프트웨어 사이의 거의 모든 것을 관리할 수 있습니다. 많은 다양한 요소를 포함하는 기술은 어렵다고 생각하는 경향이 있습니다.

하지만 실제로 WMI를 사용하여 실행할 수 있는 많은 작업은 몇 안 되는 표준 방법 중 하나를 따릅니다. 예를 들어 이미 템플릿이 거의 모든 관리 리소스에 대한 정보를 반환하는 스크립트의 기초 역할을 어떻게 수행하는지 살펴 보았습니다. 이 시리즈의 1부에서는 동일한 기본 스크립트(하나 또는 두 개의 사소한 수정)를 사용하여 설치된 메모리, 서비스, 이벤트 로그에 기록된 이벤트 등과 같이 전혀 다른 항목들에 대한 정보를 반환했습니다.

아래에서는 다음과 같은 작업에 사용할 수 있는 기본 WMI 스크립트 템플릿을 설명합니다.

• 관리 리소스의 인스턴스를 검색합니다.
• 관리 리소스의 속성을 표시합니다.
• 관리 리소스의 속성을 수정합니다.
• 관리 리소스의 메서드를 호출합니다.
• 관리 리소스의 새 인스턴스를 만듭니다.
• 관리 리소스의 인스턴스를 삭제합니다.
• 관리 리소스의 생성, 수정 및/또는 삭제를 모니터링할 이벤트를 구독합니다.

시작하기 전에 한 가지 중요한 점을 완전히 이해하고 넘어가야 합니다. 즉, WMI 관리 리소스에 할 수 있는 작업과 할 수 없는 작업은 WMI 스크립팅 라이브러리가 아니라 CIM(Common Information Model) 리포지토리의 관리 리소스 청사진(즉, 클래스 정의)에서 관리합니다. 이 시리즈의 2부가 중요한 이유가 바로 여기에 있습니다. 아직도 잘 이해가 안된다면 예를 몇 개 들어 보겠습니다.

쓰기 가능한 속성만을 수정할 수 있습니다. 쓰기 가능 속성인지는 어떻게 알 수 있을까요? WbemTest.exe, WMI CIM Studio, WMIC.exe 또는 속성의 Write 한정자를 살펴 보는 스크립트를 사용합니다. (속성 한정자를 살펴 보는 방법에 대해서는 이 시리즈의 2부에 있는 그림 7 또는 목록 3을 참조하십시오.) 속성에 대해 Write 한정자가 정의되어 있지 않으면 기본값은 FALSE이며 읽기 전용 속성이라는 의미입니다.

또 다른 예를 들어 봅시다. 리소스의 클래스 정의가 SupportsCreate 클래스 한정자를 TRUE로 설정하면 관리 리소스의 새 인스턴스를 만들 수 있습니다. 관리 리소스의 클래스 정의가 SupportsCreate를 TRUE로 설정하는지는 어떻게 알 수 있을까요? 이 시리즈의 2부에 있는 그림 7과 목록 3의 관리 리소스의 클래스 한정자를 다시 살펴 보십시오.

참고   관리 리소스의 클래스 정의가 적합한 한정자를 설정하지 못해도 실제로는 일부 관리 리소스를 생성, 업데이트 및/또는 삭제할 수 있습니다. 이런 문제는 수정되고 있습니다.

마지막으로 한 가지 더 알아둘 것이 있습니다. 다음에 나오는 모든 스크립트 템플릿은 로컬 컴퓨터에서 작동하도록 디자인되었습니다. 따라서 변수 strComputer의 값을 마침표(".")로 설정되어 있습니다. 원격 컴퓨터에 대한 스크립트를 실행하려면 strComputer의 값을 원격 컴퓨터의 이름으로 설정하면 됩니다. 예를 들어 다음 코드 줄은 atl-dc-01이라는 컴퓨터에 대해서 스크립트를 실행합니다.

strComputer = "atl-dc-01"

관리 리소스 인스턴스 검색

지금까지 SWbemServices InstancesOf 메서드를 사용하여 목록 1과 같은 관리 리소스 인스턴스를 검색했습니다.

목록   SWbemServices InstancesOf를 사용하여 서비스 정보 검색

strComputer = "."  
Set objSWbemServices = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colSWbemObjectSet = objSWbemServices.InstancesOf("Win32_Service")
For Each objSWbemObject In colSWbemObjectSet
    WScript.Echo "표시 이름:  " & objSWbemObject.DisplayName & vbCrLf & _
                 "   상태:      " & objSWbemObject.State       & vbCrLf & _
                 "   시작 모드: " & objSWbemObject.StartMode   & vbCrLf
Next

InstancesOf가 목적을 이루는 동안 인스턴스나 속성의 하위 집합만 원하는 상황이라면 어떻게 됩니까? 인스턴스 및 속성 검색을 최적화하여 네트워크 트래픽을 최대한 줄이려는 상황을 가정해 봅시다. WMI에서 다양하고 강력한 쿼리 기능을 지원한다는 것을 알면 반가울 것입니다.

WIM 쿼리는 미리 정의된 일부 기준에 일치하는 관리 리소스 요청을 실행하는 과정을 뜻합니다. 예를 들어 WMI 쿼리는 "중지됨" 상태인 StartMode of Auto로 이러한 서비스만 요청합니다.

WMI 쿼리는 관리 리소스의 인스턴스 및 해당 속성을 검색하는 데 InstancesOf 메서드보다 효과적인 메커니즘을 제공합니다. WMI 쿼리는 쿼리에 일치하는 인스턴스 및 속성만 반환하는 반면, InstancesOf는 항상 각 인스턴스에 대한 모든 속성과 지정된 리소스의 모든 인스턴스를 반환합니다. 또한 쿼리는 스크립트를 실행하는 소스 컴퓨터에서가 아닌, 개체 경로에서 식별된 대상 컴퓨터에서 처리됩니다. 따라서 WMI 쿼리는 InstancesOf와 같인 비효율적인 데이터 검색 메커니즘에서 발생하는 네트워크 사용량을 상당히 줄일 수 있습니다.

WMI를 쿼리하려면, WMI Query Language(WQL)  를 사용하여 쿼리 문자열을 만듭니다. 쿼리 문자열은 성공적으로 일치하는 결과를 얻기 위해 만족시켜야 하는 기준을 정의합니다. 쿼리 문자열이 정의되고 나면 쿼리는 SWbemServices ExecQuery 메서드를 사용하여 WMI 서비스로 제출됩니다. 쿼리를 만족시키는 관리 리소스의 인스턴스는 SWbemObjectSet 컬렉션 형태로 스크립트에 반환됩니다.

WQL 및 ExecQuery 메서드(InstancesOf가 아닌)를 사용하면 관심 있는 항목만 반환하는 스크립트를 융통성있게 작성할 수 있습니다. 예를 들어 목록 2에서처럼 기본 WQL 쿼리를 사용하여 주어진 관리 리소스의 모든 인스턴스 속성을 반환할 수 있습니다. 이것은 InstancesOf 메서드에서 반환하는 것과 동일한 정보입니다. 목록 1과 2를 비교해 보면 세째 줄의 굵게 표시된 부분이 두 스크립트 간의 유일한 차이점이라는 것을 알 수 있습니다.

목록   SWbemServices ExecQuery를 사용하여 서비스 정보 검색

strComputer = "."  
Set objSWbemServices = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colSWbemObjectSet = objSWbemServices.ExecQuery("SELECT * FROM Win32_Service")
For Each objSWbemObject In colSWbemObjectSet
    WScript.Echo "표시 이름:  " & objSWbemObject.DisplayName & vbCrLf & _
                 "   상태:      " & objSWbemObject.State       & vbCrLf & _
                 "   시작 모드: " & objSWbemObject.StartMode   & vbCrLf
Next

또한 WQL을 사용한 대상 쿼리, 즉 다음과 같은 작업을 할 수 있는 쿼리를 만들 수도 있습니다.

• 관리 리소스의 모든 인스턴스의 선택된 속성만 반환합니다.

  "SELECT DisplayName, State, StartMode FROM Win32_Service"
  

• 클래스의 선택된 인스턴스의 모든 속성을 반환합니다.

  "SELECT * FROM Win32_Service WHERE State = 'Stopped'"
  

• 클래스의 선택된 인스턴스의 선택된 속성을 반환합니다.

  "SELECT DisplayName,State,StartMode FROM Win32_Service WHERE State='Stopped'"
  

대상 쿼리를 만들면 데이터가 반환되는 속도가 눈에 띄게 향상되는 경우도 있습니다. 예를 들어 모든 이벤트 로그에 있는 모든 이벤트를 반환하는 것보다 Application 이벤트 로그에서 EventCode 0을 갖고 있는 이벤트만 반환하는 것이 훨씬 더 빠릅니다. 대상 쿼리를 사용하면 반환된 데이터로 더욱 쉽게 작업할 수 있습니다. 예를 들어 Application 이벤트에서 EventCode 0을 가진 이벤트만 필요하다고 가정해 봅시다. 대상 쿼리를 사용하면 이런 항목만 반환됩니다. 반면, InstancesOf는 모든 이벤트를 반환하므로 하나씩 개별적으로 살펴 보고 이것이 1) Application 이벤트 로그에서 나온 것인지 2) EventCode 0을 갖고 있는지 알아내야 합니다. 이 작업이 가능하기는 하지만 덜 효율적이며 사용자의 작업이 추가로 더 필요합니다.

대상 쿼리는 반환된 데이터의 양을 줄일 수 있는데 이것은 네트워크에서 실행되는 스크립트에 대한 중요한 고려 사항입니다. 표 1에는 다른 쿼리 유형에 대한 상대 수치가 나타나 있습니다. 여기서 알 수 있듯이 여러 쿼리 유형에서 반환하는 데이터 양에는 상당한 차이가 있을 수 있습니다.

표 1.   서로 다른 WMI 인스턴스 검색 메서드 및 쿼리 비교

ExecQuery가 InstancesOf보다 뛰어나다는 사실을 확신하기를 바랍니다. 이제 목록 2를 WMI 관리 리소스 인스턴스 검색에 쉽게 수정할 수 있는 일반 WMI 스크립트 템플릿으로 만들어 봅시다. 목록 3에는 첫 번째 템플릿이 들어 있습니다.

목록 3.   관리 리소스 인스턴스 검색 템플릿

strComputer = "."
strNamespace = "\root\cimv2"
strClass = "Win32_Service"

Set objSWbemServices = GetObject("winmgmts:\\" & strComputer & strNamespace)
Set colSWbemObjectSet = objSWbemServices.ExecQuery("SELECT * FROM " & strClass)

For Each objSWbemObject In colSWbemObjectSet
    WScript.Echo "표시 이름: " & objSWbemObject.DisplayName
    WScript.Echo "상태:        " & objSWbemObject.State
    WScript.Echo "시작 모드:   " & objSWbemObject.StartMode
Next

다른 WMI 클래스와 함께 이 템플릿을 사용하려면

1. strClass의 값을 대상 관리 리소스에 적합한 WMI 클래스로 설정합니다.
2. 필요한 경우 strNamespace의 값을 대상 클래스에 대한 WMI 네임스페이스로 설정합니다.
3. 속성 및 값을 반향시키는 For Each 루프 내의 명령문을 바꿉니다. 다음 줄을 제거하고 표시되는 속성 값에 적합한 코드 줄로 바꿉니다.

   WScript.Echo "표시 이름: " & objSWbemObject.DisplayName
   WScript.Echo "상태:        " & objSWbemObject.State
   WScript.Echo "시작 모드:   " & objSWbemObject.StartMode
   

팁   많은 인스턴스를 반환하는 관리 리소스로 작업하고 있다면(여기서 많은 인스턴스란 1000개 이상의 인스턴스라고 정의하겠음), 선택 플래그를 사용해서 ExecQuery의 동작을 최적화할 수 있습니다. 예를 들어 ExecQuery를 사용하여 Event Log 레코드(Win32_NTLogEvent 클래스로 모델화됨)를 쿼리한다고 가정해 봅시다. 이미 알고 있듯이 Event Log(s)는 수천 개의 레코드를 포함할 수 있습니다. 기본적으로 Event Log 쿼리와 같이 많은 결과 집합을 반환하는 쿼리와 관련된 성능 문제를 발견할 수도 있습니다. 그 이유는 WMI가 인스턴스 전부 또는 일부에 대한(또는 Event Log 레코드 전부 또는 일부에 대한) SWbemObject 참조를 캐시하는 방식과 관련이 있습니다. 이러한 문제를 피하기 위해서는 아래에서 설명하는 것처럼 포워드 전용 SWbemObjectSet를 반환하도록 ExecQuery를 사용하면 됩니다.

strComputer = "."
strNamespace = "\root\cimv2"
strClass = "Win32_NTLogEvent"

Const wbemFlagReturnImmediately = &h10
Const wbemFlagForwardOnly = &h20

Set objSWbemServices = GetObject("winmgmts:\\" & strComputer & strNamespace)
Set colSWbemObjectSet = objSWbemServices.ExecQuery("SELECT * FROM " & strClass, _
                        "WQL" _
                        wbemFlagReturnImmediately + wbemFlagForwardOnly)

' 나머지 스크립트를 여기에 삽입합니다(예: For Each Next 루프)...

참고    wbemFlagReturnImmediately 플래그(이 플래그는 앞에서 잠깐 다룬 열거 중 하나에 정의됨)는 기본 ExecQuery 동작이며 반동기적입니다. 최적화 방법 중 중요한 요소는 wbemFlagForwardOnly 플래그를 추가하는 것입니다. wbemFlagReturnImmediately와 wbemFlagForwardOnly를 함께 사용하면 포워드 전용 열거자가 나타납니다. 포워드 전용 열거자는 WMI가 SWbemObjectSet에 개체에 대한 참조를 유지하지 않기 때문에 기본 열거자보다 더 빨리 실행합니다.

관리 리소스 속성 표시

목록 3에 있는 스크립트의 한가지 제한 사항은 검색 및 표시할 모든 속성의 이름을 미리 알아야 한다는 것입니다. 리소스의 모든 속성 값을 표시하고 싶지만 속성의 이름을 모르거나 각 속성 값을 표시하는 데 필요한 40 또는 50개의 코드 줄을 입력하고 싶지 않다면 어떻게 해야 할까요? 이런 경우 목록 4의 템플릿을 사용할 수 있는데 이 템플릿은 클래스에 있는 각 속성 값을 자동으로 검색하여 표시합니다.

목록 4.   Scriptomatic lite 템플릿

strComputer = "."
strNamespace = "\root\cimv2"
strClass = "Win32_Process"

Set objSWbemServices = GetObject("winmgmts:\\" & strComputer & strNamespace)
Set colSWbemObjectSet = objSWbemServices.ExecQuery("SELECT * FROM " & strClass)

Wscript.Echo "Scriptomatic Lite - 클래스: " & strClass
Wscript.Echo "===========================" & String(Len(strClass), "=") & vbCrLf

intInstance = 1
For Each objSWbemObject In colSWbemObjectSet
    WScript.Echo "인스턴스: " & intInstance & vbCrLf & "--------------"
    For Each objSWbemProperty In objSWbemObject.Properties_
        strPropertyValue = ConvertPropertyValueToString(objSWbemProperty.Value)
        WScript.Echo objSWbemProperty.Name & ": " & strPropertyValue
    Next
    WScript.Echo
    intInstance = intInstance + 1
Next

Function ConvertPropertyValueToString(ByVal PropertyValue)
    If IsObject(PropertyValue) Then
        ConvertPropertyValueToString = "<CIM_OBJECT (embedded SWbemObject)>"
    ElseIf IsNull(PropertyValue) Then
        ConvertPropertyValueToString = "<NULL>"
    ElseIf IsArray(PropertyValue) Then
        ConvertPropertyValueToString = Join(PropertyValue, ",")
    Else
        ConvertPropertyValueToString = CStr(PropertyValue)
    End If
End Function

다른 WMI 클래스와 함께 이 템플릿을 사용하려면

1. strClass의 값을 대상 관리 리소스에 적합한 WMI 클래스로 설정합니다.
2. 필요한 경우 strNamespace의 값을 대상 클래스에 대한 WMI 네임스페이스로 설정합니다.

관리 리소스 속성 수정

Windows 2000에서 WMI는 주로 읽기 전용 기술입니다. Windows 2000 root\cimv2 네임스페이스에 정의된 4,395개 속성 중에서 39개만 쓰기 가능한 속성입니다. Microsoft Windows XP에서는 그 수가 더 많아져서 대략 6560개 속성 중 145개가 쓰기 가능한 속성입니다. 이 수는 Windows Server 2003에서는 더욱 많아졌습니다.

목록 5의 템플릿은 쓰기 가능한 속성을 수정하는 방법을 보여줍니다. 스크립트는 Win32_OSRecoveryConfiguration 클래스로 모델화된 관리 리소스의 모든 인스턴스를 검색합니다. 이 경우 클래스에는 단 하나의 인스턴스만 포함됩니다. 스크립트는 세 개의 속성(DebugInfoType, DebugFilePath, OverWriteExistingDebugFile)에 대한 새 값을 제공한 다음, SWbemObject Put_ 메서드를 사용하여 변경 사항을 적용하고 운영 체제 복구 옵션을 구성합니다. Put_ 메서드를 호출하지 않으면 변경 사항이 적용되지 않습니다.

참고   이 템플릿은 쓰기 가능한 속성에만 사용할 수 있습니다. 읽기 전용 속성을 변경하려고 하면 오류가 발생합니다. 쓰기 가능한 속성인지 알려면 속성의 Write 한정자를 살펴 보십시오.

목록 5.   관리 리소스의 쓰기 가능한 속성을 수정하는 템플릿

strComputer = "."
strNamespace = "\root\cimv2"
strClass = "Win32_OSRecoveryConfiguration"

Set objSWbemServices = GetObject("winmgmts:\\" & strComputer & strNamespace)
Set colSWbemObjectSet = objSWbemServices.ExecQuery("SELECT * FROM " & strClass)

For Each objSWbemObject In colSWbemObjectSet
    objSWbemObject.DebugInfoType = 1
    objSWbemObject.DebugFilePath = "c:\tmp\memory.dmp"
    objSWbemObject.OverWriteExistingDebugFile = False
    objSWbemObject.Put_
Next

For Each 루프에서 SWbemObject가 사용되는 방식은 다음과 같습니다. 1) Win32_OSRecoveryConfiguration 클래스에서 정의한 속성에 직접 액세스하고 수정합니다. 2) 자체 Put_ 메서드를 호출하여 변경 사항을 적용합니다.

쓰기 가능한 속성을 구현하는 다른 WMI 클래스와 함께 이 템플릿을 사용하려면

1. strClass의 값을 대상 관리 리소스에 적합한 WMI 클래스로 설정합니다.
2. 필요한 경우 strNamespace의 값을 대상 클래스에 대한 WMI 네임스페이스로 설정합니다.
3. 새 속성 값을 구성하는 For Each 루프 내의 명령문을 바꿉니다. 다음 줄을 제거하고 수정되는 속성에 적합한 코드 줄로 바꿉니다.

   objSWbemObject.DebugInfoType = 1
   objSWbemObject.DebugFilePath = "c:\tmp\memory.dmp"
   objSWbemObject.OverWriteExistingDebugFile = False
   

관리 리소스 메서드 호출

관리 리소스의 클래스 정의에 정의되어 있는 메서드는 관리 리소스에서 작업을 실행할 수 있게 해줍니다. 예를 들어 Win32_Service 클래스에는 서비스를 시작 및 중단시키는 작업을 수행하게 해주는 메서드가 있습니다. Win32_NTEventlogFile 클래스에는 이벤트 로그를 백업 및 지우는 메서드가 있습니다. Win32_OperatingSystem 클래스에는 컴퓨터를 다시 부팅하거나 종료시키는 메서드가 있습니다.

목록 6은 WMI 관리 리소스 메서드를 호출하는 스크립트 작성에 사용할 수 있는 템플릿을 제공합니다. 이 특정 스크립트는 Win32_Service 클래스의 StopService 메서드를 사용하여 로컬 컴퓨터에서 Alerter 서비스를 중지시킵니다.

참고   관리 리소스의 클래스 정의에 정의된 메서드를 호출하기 전에 메서드를 구현해야 합니다. 메서드가 구현되었는지는 어떻게 알 수 있을까요? 메서드의 구현된 한정자를 살펴 봅니다. TRUE 값은 메서드가 공급자에서 제공한 구현을 가지고 있음을 나타냅니다. 메서드가 구현되어도 일부 메서드는 구현된 한정자를 정의하지 않는다는 사실을 알아야 합니다. 아래에 있는 Win32_Service StopService 메서드는 이러한 메서드의 예입니다. 메서드가 구현되었는지 아닌지를 알아내는 아래 코드 줄을 사용할 때는 약간의 시행 착오가 있을 수 있습니다. 앞서 말했듯이 이런 문제는 수정되고 있습니다.

목록 6.   관리 리소스 메서드 호출 템플릿

strComputer = "."
strNamespace = "\root\cimv2"
strClass = "Win32_Service"
strKey = "Name"
strKeyValue = "Alerter"

Set objSWbemServices = GetObject("winmgmts:\\" & strComputer & strNamespace)
Set colSWbemObjectSet = objSWbemServices.ExecQuery _
    ("SELECT * FROM " & strClass & " WHERE " & strKey & "='" & strKeyValue & "'")

For Each objSWbemObject in colSWbemObjectSet
     objSWbemObject.StopService()
Next

다른 WMI 클래스와 함께 이 템플릿을 사용하려면

1. strClass의 값을 대상 관리 리소스에 적합한 WMI 클래스로 설정합니다.
2. 필요한 경우 strNamespace의 값을 대상 클래스에 대한 WMI 네임스페이스로 설정합니다.
3. strKey의 값을 WHERE 절의 기반을 형성하는 속성 이름으로 설정합니다.
4. strKeyValue의 값을 strKey에 적합한 값으로 설정합니다.
5. 메서드를 호출하는 For Each 루프 내의 명령문을 바꿉니다. 다음 줄을 제거하고 호출되는 메서드에 적합한 코드 줄로 바꿉니다. 필요한 경우 적합한 메서드 매개 변수를 포함해야 합니다.

   objSWbemObject.StopService()
   

관리 리소스의 새 인스턴스 생성

일부 WMI 클래스는 모델화한 리소스의 새 인스턴스를 만들 수 있게 해줍니다. 예를 들어 Win32_Environment 클래스를 사용하여 환경 변수를 만들 수 있고 Win32_Process 클래스를 사용하여 프로세스를 만들 수 있으며 Win32_Share 클래스를 사용하여 공유 리소스를 만들어 명명할 수 있습니다.

리소스의 새 인스턴스를 만들기 전에 관리 리소스의 클래스가 생성 작업을 지원하는지 확인해야 합니다. 이때 클래스의 SupportsCreate 식별자를 살펴보면 됩니다. TRUE 값은 클래스가 인스턴스의 생성을 지원함을 나타냅니다. 기본값은 FALSE입니다. 일단 클래스가 생성 작업을 지원한다는 것을 알아내면 새 인스턴스를 만드는 데 사용되는 메서드를 결정해야 합니다. 새 인스턴스를 만드는 방법은 다음 두 가지가 있습니다.

1. 클래스가 PutInstance 값으로 CreateBy 클래스 한정자를 정의하는 경우 SWbemObject SpawnInstance_ 및 Put_ 메서드를 사용하여 새 인스턴스를 만듭니다.
2. CreateBy 클래스 한정자에 할당된 값이 PutInstance 이외의 값(예: Create)인 경우, CreateBy 한정자가 식별한 메서드를 사용하여 새 인스턴스를 만듭니다.

각각에 대한 템플릿을 살펴 봅시다.

목록 7은 리소스의 클래스 정의가 SupportsCreate를 TRUE로 설정하고 CreateBy를 PutInstance로 설정할 때 어떻게 리소스의 인스턴스를 만드는지 보여줍니다. 대상 컴퓨터에서 WMI에 연결한 이후에는 생성하려는 대상에 대한 청사진(즉, 클래스 정의)을 먼저 얻어야 합니다. 이렇게 하려면 SWbemServices Get 메서드를 사용하여 클래스의 검색 인스턴스가 아닌 실제 WMI 클래스를 반입합니다. 클래스를 나타내는 개체를 얻고 나면 SWbemObject SpawnInstance_ 메서드를 사용하여 클래스의 새로운 "빈" 인스턴스를 만듭니다. 새 인스턴스의 속성을 설정하고 SWbemObject Put_ 메서드를 호출하여 새 인스턴스를 만듭니다.

목록 7.   SpawnInstance_ 및 Put_을 사용하여 새 인스턴스를 생성하는 템플릿

strComputer = "."
strNamespace = "\root\cimv2"
strClass = "Win32_Environment"

Set objSWbemServices = GetObject("winmgmts:\\" & strComputer & strNamespace)
Set objSWbemObject = objSWbemServices.Get(strClass)
Set objNewSWbemObject = objSWbemObject.SpawnInstance_()

objNewSWbemObject.Properties_.Item("Name") = "TMPSHARE"
objNewSWbemObject.Properties_.Item("UserName") = "<SYSTEM>"
objNewSWbemObject.Properties_.Item("VariableValue") = "c:\tmp"

objNewSWbemObject.Put_

PutInstance를 지원하는 다른 WMI 클래스와 함께 이 템플릿을 사용하려면

1. strClass의 값을 대상 관리 리소스에 적합한 WMI 클래스로 설정합니다.
2. 필요한 경우 strNamespace의 값을 대상 클래스에 대한 WMI 네임스페이스로 설정합니다.
3. 환경 변수에 대한 값을 구성하는 명령문을 바꿉니다. 다음 줄을 제거하고 생성될 개체에 적합한 코드 줄로 바꿉니다.

   objNewSWbemObject.Properties_.Item("Name") = "TMPSHARE"
   objNewSWbemObject.Properties_.Item("UserName") = "<SYSTEM>"
   objNewSWbemObject.Properties_.Item("VariableValue") = "c:\tmp"
   

팁   SWbemObject SpawnInstance_ 및 Put_ 메서드를 사용하여 새 인스턴스를 만들 때 클래스의 모든 키 속성에 대한 값을 제공해야 합니다. 예를 들어 목록 7에서 사용된 Win32_Environment 클래스는 Name 및 UserName 두 개의 키 속성을 정의합니다. 클래스의 키 속성은 어떻게 결정할까요? WbemTest.exe, WMI CIM Studio, WMIC.exe 또는 속성의 Key 한정자를 살펴 보는 스크립트를 사용합니다.

목록 8은 리소스의 클래스 정의가 자체 생성 메서드를 제공할 때 리소스의 인스턴스를 만드는 방법을 보여줍니다. 대상 컴퓨터에서 WMI에 연결한 이후에는 생성하려는 대상에 대한 청사진(즉, 클래스 정의)을 먼저 얻어야 합니다. 이렇게 하려면 SWbemServices Get 메서드를 사용하여 클래스의 검색 인스턴스가 아닌 실제 WMI 클래스를 반입합니다. 클래스를 나타내는 개체를 갖게 되면 SWbemObject를 사용하여 클래스의 CreateBy 한정자가 식별한 메서드를 호출합니다. 목록 8의 스크립트 템플릿은 Win32_Share Create 메서드를 사용하여 새 공유 폴더를 만듭니다.

목록 8.   관리 리소스 메서드를 사용하여 새 인스턴스를 생성하는 템플릿

strComputer = "."
strNamespace = "\root\cimv2"
strClass = "Win32_Share"

Const SHARED_FOLDER = 0
strPath = "c:\tmp"
strShareName = "tmp"
intMaximumAllowed = 1
strDescription = "임시 공유"

Set objSWbemServices = GetObject("winmgmts:\\" & strComputer & strNamespace)
Set objSWbemObject = objSWbemServices.Get(strClass)

intReturnValue = objSWbemObject.Create(strPath, _
                                       strShareName, _
                                       SHARED_FOLDER, _
                                       intMaximumAllowed, _
                                       strDescription)

WScript.Echo "반환 값: " & intReturnValue

사용자 지정 생성 메서드를 제공하는 다른 WMI 클래스와 함께 이 템플릿을 사용하려면

1. strClass의 값을 대상 관리 리소스에 적합한 WMI 클래스로 설정합니다.
2. 필요한 경우 strNamespace의 값을 대상 클래스에 대한 WMI 네임스페이스로 설정합니다.
3. 생성 메서드에 전달된 매개 변수를 나타내는 변수 초기화 문을 바꿉니다. 다음 줄을 제거하고 생성될 개체에 적합한 코드 줄로 바꿉니다.

   Const SHARED_FOLDER = 0
   strPath = "c:\tmp"
   strShareName = "tmp"
   intMaximumAllowed = 1
   strDescription = "임시 공유"
   

4. 생성 중인 관리 리소스에 적합한 메서드로 Win32_Share Create 메서드 호출을 바꿉니다. 다음 줄을 제거하고 생성될 개체에 적합한 코드 줄로 바꿉니다.

   intReturnValue = objSWbemObject.Create(strPath, _
                                          strShareName, _
                                          SHARED_FOLDER, _
                                          intMaximumAllowed, _
                                          strDescription)
   

팁   관리 리소스의 클래스 정의에서 제공하는 메서드를 사용하여 새 인스턴스를 만들 때 메서드에서 정의한 필수 매개 변수에 대한 값을 제공해야 합니다. 예를 들어 목록 8에서 사용된 Win32_Share 클래스는 세 가지 필수 매개 변수(Path, Name, Type)를 정의합니다. 메서드의 필수 매개 변수는 어떻게 결정할까요? WMI SDK에서 관리 리소스의 클래스 정의  를 참조하십시오.

관리 리소스 인스턴스 삭제

관리 리소스의 새 인스턴스를 만들 수 있으면 인스턴스를 삭제할 수도 있습니다. 사실 삭제할 수 있는 관리 리소스 인스턴스를 관리하는 규칙은 생성 작업을 관리하는 규칙과 매우 유사합니다. 필수 조건을 살펴본 다음 예를 몇 개 살펴 보겠습니다.

리소스의 인스턴스를 삭제하기 전에 관리 리소스의 클래스가 삭제 작업을 지원하는지 확인해야 합니다. 이 작업을 할 때 클래스의 SupportsDelete 한정자를 살펴봅니다. TRUE 값은 클래스가 삭제를 지원함을 나타냅니다. 기본값은 FALSE입니다. 일단 클래스가 삭제를 지원한다는 것을 알아내면 인스턴스 삭제에 사용되는 메서드를 결정해야 합니다. 두 가지 방법으로 인스턴스를 삭제할 수 있습니다.

1. 클래스가 DeleteInstance 값으로 DeleteBy 클래스 한정자를 정의하는 경우 SWbemServices Delete 또는 SWbemObject Delete_ 메서드를 사용하여 인스턴스를 삭제할 수 있습니다.
2. DeleteBy 클래스 한정자에 할당된 값이 DeleteInstance 이외의 값(예: delete)인 경우 DeleteBy 한정자가 식별한 메서드를 사용하여 인스턴스를 삭제합니다.

목록 9와 10은 목록 7에서 만들어진 환경 변수를 삭제하는 방법을 보여줍니다. 목록 9는 SWbemServices Delete 메서드를 사용하고, 목록 10은 SWbemObject Delete_ 메서드를 사용합니다. 리소스의 클래스 정의가 SupportsDelete를 TRUE로 설정하고 DeleteBy를 DeleteInstance로 설정할 때 목록 9 또는 10을 사용합니다.

목록 9.   SWbemServices Delete 메서드를 사용하여 인스턴스를 삭제하는 템플릿

strComputer = "."
strNamespace = "\root\cimv2"
strInstance = "Win32_Environment.Name='TMPSHARE',UserName='<SYSTEM>'"

Set objSWbemServices = GetObject("winmgmts:\\" & strComputer & strNamespace)
objSWbemServices.Delete strInstance

목록 10.   SWbemObject Delete_ 메서드를 사용하여 인스턴스를 삭제하는 템플릿

strComputer = "."
strNamespace = "\root\cimv2"
strInstance = "Win32_Environment.Name='TMPSHARE',UserName='<SYSTEM>'"

Set objSWbemServices = GetObject("winmgmts:\\" & strComputer & strNamespace)
Set objSWbemObject = objSWbemServices.Get(strInstance)
objSWbemObject.Delete_

DeleteInstance를 지원하는 다른 WMI 클래스와 함께 이 템플릿을 사용하려면

1. strInstance의 값을 대상 관리 리소스 인스턴스에 적합한 WMI 클래스, 키, 키 값으로 설정합니다.

목록 11에서는 목록 8에서 만든 공유 폴더를 삭제하면서 리소스의 클래스 정의에서 자체 삭제 메서드를 제공할 때 리소스의 인스턴스를 삭제하는 방법을 보여 줍니다. 잠시 목록 10과 11을 비교해 봅시다. strInstance에 할당된 값 외에 다른 차이점이 보입니까? 목록 10은 SWbemObject Delete_ 메서드(밑줄에 주의)를 사용하여 관리 리소스의 클래스 정의가 DeleteBy 클래스 한정자를 DeleteInstance로 설정할 때 인스턴스를 삭제합니다. 반면 목록 11은 Win32_Share Delete 메서드를 사용하고 있습니다.

목록 11.   관리 리소스 메서드를 사용하여 인스턴스를 삭제하는 템플릿

strComputer = "."
strNamespace = "\root\cimv2"
strInstance = "Win32_Share.Name='tmp'"

Set objSWbemServices = GetObject("winmgmts:\\" & strComputer & strNamespace)
Set objSWbemObject = objSWbemServices.Get(strInstance)
objSWbemObject.Delete

사용자 지정 삭제 메서드를 제공하는 다른 WMI 클래스와 함께 이 템플릿을 사용하려면

1. strInstance의 값을 대상 관리 리소스 인스턴스에 적합한 WMI 클래스, 키, 키 값으로 설정합니다.

이벤트 구독

자. 이제 프로그래머들의 첫 번째 미덕인 게으름을 시험할 때인 것 같습니다. 걱정하지 마십시오. 이벤트 구독에 대해서도 다룰 것입니다. 그러나 여기에서 이벤트 구독을 다루기보다는 TechNet의 Tales from the Script  칼럼의 A Brief Introduction to WMI Events  를 소개해 드립니다. 이 사이트에서 WMI 이벤트 구독에 대한 소개 뿐 아니라 다른 스크립팅 소스에 대한 내용도 찾아볼 수 있습니다.

결론

이 기사를 마지막으로 WMI 스크립팅에 대한 설명을 마치겠습니다. 물론 다룰 내용이 더 많기는 합니다. 여러분이 알고 싶은 스크립팅 클리닉 주제에 대한 제안을 보내주시면 기꺼이 경청하겠습니다. scripter@microsoft.com으로 메일을 보내시거나 이 페이지의 맨 위에 있는 사용자 의견란에 의견을 남겨 주십시오.

마지막으로 말씀드릴 것이 있습니다. 이 기사의 시작 부분에서 언급했던 시스템 관리 자동화 서적인 Microsoft Windows 2000 Scripting Guide  를 기억하십니까? 기술 서적을 아주 저렴한 가격으로 판매하는 온라인 서점인 Bookpool  에서 지금 바로 한 부 구입하시는 것이 좋습니다. 시간과 비용을 절약하려는 분들을 위해 이 책 전체(1328페이지)를 온라인  으로 게시했으므로 이용하시기 바랍니다. 아래의 스크립팅 클리닉 팀이 여러분의 도움 요청에 신속하게 답변을 드리지 못할 경우에는 이 온라인 가이드를 보시면 많은 도움이 될 것입니다. 이 책의 일부나 전부를 읽을 기회가 있으시면 이 책에 대한 서평을 보내주시면 감사하겠습니다. 앞으로 좀 더 나은 내용으로 업데이트된 가이드를 만드는 데 최선을 다하겠습니다.

스크립팅 클리닉

Greg Stemp는 오랫동안 전국 최고의 스크립팅 대가 중 한 사람으로 또한 세계적인 풋볼 코치로 널리 인정받아 왔습니다. 그런데 어떻게 풋볼 코치가 이런 일을 하게 되었냐구요? 그는 "해고"되었습니다. Greg Stemp는... 이제 이렇게 말할 수 밖에 없군요. 좋습니다. Greg Stemp는 Microsoft에서 System Administration Scripting Guide의 수석 집필진으로 일하고 있습니다.

Dean Tsaltas는 노바스코샤 출신으로 레드먼드에 살고 있습니다. 그는 영어를 유창하게 구사하며 심지어 친구와 가족들의 액센트도 비웃을 정도로 영어 실력이 뛰어납니다. 그는 할머니와 부모님이 그가 애지중지하는 C-64를 사주고 Compute!' Gazette를 구독하게 해 준 어린 시절에 컴퓨팅을 시작했습니다! 그는 수년간 Microsoft에서 재직 중이며, 집과 벤쿠버에 있는 친구와 가족에 대해 다음과 같은 메시지를 전하고 있습니다. "아직 Bill을 만나지 못했어요!"

Bob Wells는 관심을 갖고 있는 사람이면 누구에게나 스크립팅의 가치를 역설합니다. Bob이 대부분의 사람들보다 스크립팅에 대해서 더 많이 알고 있다는 소문이 있습니다. 여가 시간에 Bob은 System Administration Scripting Guide에 기고합니다.

Ethan Wilansky는 많은 시간을 저술 및 컨설팅 활동에 보냅니다. 그리고 스크립팅, 요가, 원예 및 가정일에 열심입니다. 현재는 쓰레기를 버리고 설겆이를 하는 스크립트를 만드는 일에 전념하고 있습니다.