1. 문자열의 길이구하기 : LEN( ) 예) Print Len("abcd") -> 4를 출력

2. 문자의 아스키코드 구하기 : ASC( ) 예) Print Asc("A") -> 65를 출력

3. 아스키코드를 문자로 변환 : CHR( ) 예) Print Chr(65) -> "A"를 출력

4. 문자열을 숫자로 바꾸기 : VAL( ) 예) Print Val("12")+Val("12") -> 24를 출력

5. 숫자를 문자열로 바꾸기 : STR( )/ CSTR( ) 예) Print Str(12) -> " 12"를 출력 예)Print Cstr(12) -> "12"를 출력

6. 문자열의 왼쪽부분 얻기: LEFT( ) 예) Print Left("abcd",2) -> "ab"를 출력

7. 문자열의 오른쪽부분 얻기 : RIGHT ( ) 예) Print Right("abcd",2) -> "cd"를 출력

8. 문자열의 일부부분 얻기 : MID( ) 예) Print Mid("abcd",2,2) -> "bc"를 출력 예) Print Mid("abcd",2) -> "bcd"를 출력

9. 문자열에 원하는 부분문자열의 위치 얻기 : INSTR( ) 예) Print Instr(1,"abcd","b") -> 2를 출력 예) Print Instr("abcd","b") -> 2를 출력

10. 실수의 소숫점이하를 버리고 정수로 만들기 : INT( ) 예) Print Int(3.14) -> 3을 출력

11. 대문자를 소문자로 바꾸기 : LCASE( ) 예) Print Lcase("A") -> "a"를 출력

12. 소문자를 대문자로 바꾸기 : UCASE( ) 예) Print Ucase("a") -> "A"를 출력

13. 현재 날짜/시간정보 얻기 : NOW 예) Print Year(Now) -> 2005를 출력(시스템 연도가 2005인 경우)

14. 날짜 정보 얻기 년:YEAR( ) 월:MONTH( ) 일:DAY( ) 요일:WEEKDAY( )

15. 시간 정보 얻기 시:HOUR( ) 분:MINUTE ( ) 초:SECOND( )

16: 난수발생 : RND 예) Print Int(Rnd*10) -> 0~9까지 난수 발생후 출력 Rnd:0~1사이 실수 난수 발생

17. 절대값 : ABS 예) Print Abs(-8) -> 8을 출력

18. 삼각함수 SIN( )/ COS( )/ TAN( )

19. 제곱근: SQR( ) 예) Print Sqr(9) -> 3을 출력

20. 지정된 파일 실행하기 : SHELL( )

21. 지정된 형식의 문자열로 변환하기 : FORMAT( ) 예) Print Format(1234,"#,###") -> 1,234를 출력

22. 숫자인가를 판단 : ISNUMERIC( ) 예) If Isnumeric(a) Then Print "숫자입니다" : a변수의 값이 숫자이면 "숫자입니다"를 출력

WScript

http://nazelm.egloos.com/938347

WSH - WScript 와 CSciprt

http://cafe.naver.com/randomaccess.cafe?iframe_url=/ArticleRead.nhn%3Farticleid=54

http://www.mungchung.com/mianamssi/articles/S011-trans_code.htm

<script language="javascript">
function funESC(p_str){
d0cument.frm.str_1.value = escape(p_str);
}

function funUnESC(p_str){
d0cument.frm.str_1.value = unescape(p_str);
}
</script>

<form name="frm">
변경전 : <input type="text" name="str" size="50"><br>
변경후 : <input type="text" name="str_1" size="50">
<br><br>
<input type="button" value="escape" onClick="funESC(frm.str.value)">
<input type="button" value="unescape" onClick="funUnESC(frm.str.value)">
</form>

http://user.chollian.net/~iteach/
http://myhome.naver.com/rangs75/cafe/appendix/specialchar.htm#jssc

주로 많이 사용되는 문자코드만 몇개 적어보겠습니다.^^

출처: http://blog.empas.com/woo4761/9330195

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 인스턴스 검색 메서드 및 쿼리 비교

메서드/WQL 쿼리	반환된 바이트
objSWbemServices.InstancesOf("Win32_Service")	157,398
objSWbemServices.ExecQuery("SELECT * FROM Win32_Service")	156,222
objSWbemServices.ExecQuery("SELECT Name FROM Win32_Service")	86,294
objSWbemServices.ExecQuery("SELECT StartMode FROM Win32_Service")	88,116
objSWbemServices.ExecQuery("SELECT StartMode FROM Win32_Service WHERE State='Running'")	52,546
objSWbemServices.ExecQuery("SELECT StartMode, State FROM Win32_Service WHERE State='Running'")	56,314
objSWbemServices.ExecQuery("SELECT * FROM Win32_Service WHERE Name='WinMgmt'")	27,852
objSWbemServices.Get("Win32_Service.Name='WinMgmt'")	14,860

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 WindowsXP에서는 그 수가 더 많아져서 대략 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페이지)를 온라인으로 게시했으므로 이용하시기 바랍니다. 아래의 스크립팅 클리닉 팀이 여러분의 도움 요청에 신속하게 답변을 드리지 못할 경우에는 이 온라인 가이드를 보시면 많은 도움이 될 것입니다. 이 책의 일부나 전부를 읽을 기회가 있으시면 이 책에 대한 서평을 보내주시면 감사하겠습니다. 앞으로 좀 더 나은 내용으로 업데이트된 가이드를 만드는 데 최선을 다하겠습니다.

http://www.microsoft.com/korea/msdn/columns/contents/scripting/scripting01142003/default.aspx

출처 : Tong - 뱃살날다님의 프로그래밍통

WMI 스크립팅 입문: 2부

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를 사용한 서비스 정보 검색

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

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

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

두 가지 이유 모두 여러분이 사용하는 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 스크립트는 지난 달에 간단히 다루었던 초기 연결 단계의 일부로서 다음과 같이 네임스페이스에 연결됩니다.

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

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)의 연결 단계는 다음과 같이 작성됩니다.

대상 네임스페이스를 연결 문자열에 추가하면 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를 사용한 스크립팅용 기본 네임스페이스 검색

목록 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를 사용한 스크립팅용 기본 네임스페이스 설정

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

네임스페이스 목록

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

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

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

그림 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 네임스페이스 검색

그림 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 공급자 검색

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 네임스페이스에 정의된 모든 클래스 검색

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 네임스페이스에 존재하는지 알아낼 수 있습니다.

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

• 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 네임스페이스, 관리 리소스의 클래스 이름, 클래스의 키 속성 및 키 속성의 값 순으로 이루어진 개체 경로가 있습니다. 대괄호([])는 개체 경로의 네 가지 허용 가능한 부분을 구분할 뿐이며, 개체 경로의 일부가 아닙니다.

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 속성 검색

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

그림 9. GetProperties.vbs 출력

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

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

그림 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 클래스 한정자 검색

그림 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)으로 스크립트를 저장하고 아래에 있는 명령줄을 사용하여 스크립트를 실행합니다.

그림 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 네임스페이스에 정의된 추상 클래스 형식 나열

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

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

http://www.microsoft.com/korea/msdn/columns/contents/scripting/scripting08132002/default.aspx

출처 : Tong - 뱃살날다님의 프로그래밍통