EgoCube.IISWebAdmin 컴포넌트 04. (버전 1.2.0.60)

본문에서는 마이너 업그레이드 된 EgoCube.IISWebAdmin 컴포넌트 버전 1.2.0.60에 대해서 살펴본다. 이 버전은 EgoCube.IISWebAdmin 컴포넌트의 기존 버전에 세 개의 추가적인 메서드가 더해진 것으로, 이 메서드들은 그동안 사용자들로부터 가장 요구가 많았던 내용들을 반영한 것이다. 구체적으로 말하자면 가상 디렉터리를 생성하거나 제거할 수 있는 기능과 가상 웹 서버를 제거할 수 있는 기능이 추가된 버전이라고 생각하면 된다.

고백하건데 부끄럽게도 이 컴포넌트는 이미 일 년도 전에 완성이 되어 있었으나, 고질적인 필자의 게으름으로 인해서 지금에서야 소개를 드리게 된 것이다. 소스의 주석 부분에 최종 수정일이 작년 6월 26일로 기재되어 있다는 것을 감안해본다면 거의 만으로 일 년 만에서야 비로서 이 글을 쓸 생각을 한 셈이다. 그나마 FileCube에는 몇 달 전부터 소스 파일과 설치 파일이 올라가 있었지만 사실 공지나 기타 언급이 없었으므로 이 또한 있으나 마나였던 셈이다.

그리고, 새로 추가된 세 개의 메서드를 제외한 나머지 기존 컴포넌트 요소들에 대한 자세한 설명은 구 버전 컴포넌트에 관해서 설명한 필자의 지난 글들을 참고하기 바란다. 물론 흐름상 어쩔수 없이 동일한 설명을 반복하지 않을 수 없는 부분도 가끔 있겠지만, 가급적 본문에서는 이미 설명했던 내용들을 다시 반복해서 설명하지는 않을 생각이다. 다음의 링크들은 구 버전 EgoCube.IISWebAdmin 컴포넌트(DLL 버전 1.0.0.37)에 대한 내용들을 담고 있는 관련 문서들이다. 여기에 설명된 내용들은 버전 1.2.0.60에서도 정확하게 동일하게 적용된다.

• EgoCube.IISWebAdmin 컴포넌트 01.
• EgoCube.IISWebAdmin 컴포넌트 02.
• EgoCube.IISWebAdmin 컴포넌트 03.

이번 새 버전의 EgoCube.IISWebAdmin 컴포넌트의 소스 코드와 설치 파일은 언제나처럼 FileCube에서 다운로드 받거나 또는 다음의 링크를 통해서 다운로드 받을 수 있다. 그리고, 다운로드 받은 설치 파일을 사용해서 컴포넌트를 설치할 때, 가급적이면 기존에 설치되어 있던 구 버전을 완벽하게 제거하고 나서 인스턴스가 생성되지 않는다는 것까지 확인하고 난 다음, 다시 새 버전을 설치할 것을 권장한다. 왜냐하면 구 버전의 컴포넌트가 현재 임의의 ASP 프로그램에 의해서 사용되고 있는 상태에서 해당 버전을 제거하지 않고 새 버전의 컴포넌트를 설치하면 간혹 웹 서비스가 재시작되기 전까지는 IIS에서 계속해서 구 버전만을 인식하는 경우가 발생하기도 하기 때문이다.

IISWebAdmin_Src_1.2.0.60.zip (30k)
IISWebAdmin_Setup_1.2.0.60.zip (2,224k)

제공되는 설치 프로그램으로 컴포넌트를 설치하다 보면 위에서 설명한 것과 같이 했음에도 불구하고 여러가지 주변 환경에 따라 설치가 진행되는 과정 도중에 오류가 발생하고 설치가 제대로 마무리되지 않는 경우가 생기기도 한다. 대부분 그 원인은 필자가 패키지 및 배포 마법사로 제작한 설치 프로그램이 그다지 완벽하지 못한 탓으로서 그런 경우에는 설치 프로그램에 포함된 IISWebAdmin.CAB 파일의 압축을 풀고 RegSvr32.exe 유틸리티를 사용해서 IISWebAdmin.dll 파일을 시스템에 직접 등록하면 된다.

이 경우, 반드시 %SystemRoot%\System32 폴더에 VB6KO.DLL이라는 파일이 존재하고 있는지를 먼저 확인하도록 한다. 만약, 이 파일이 존재하지 않으면 일단 컴포넌트가 설치된다고 하더라도 정상적으로 동작되지 않을 것이다. 해당 폴더에 이 파일도 없고 개인적으로 집에서 혼자 공부하는 경우와 같이 달리 파일을 구할 곳도 마땅치 않은 경우에는 VB6KO.DLL 파일 역시도 IISWebAdmin.CAB 파일안에 포함되어 있으므로 참고하기 바란다. VB6KO.DLL 파일은 COM DLL이 아니므로 RegSvr32.exe 등을 사용해서 레지스트리에 등록할 필요는 없으며 단순히 해당 폴더에 복사하기만 하면 된다.

만약, 이런저런 방법들을 모두 시도해봐도 계속해서 문제가 발생하고 다른 방법들도 여의치가 않다면, 단순하게 컴파일을 한 번 해주는 것도 방법이다. 그리고, 현재 사용하고 있는 운영 체제와 그 버전에 맞는 ADSI 2.5 를 아래의 링크에서 다운로드 받아 설치하는 것을 권장한다. 비록 한글 버전은 제공되고 있지 않지만 영문 버전을 설치해도 무방하다.

Active Directory Services Interfaces 2.5 : [Microsoft Windows NT Server 4.0; ADSI 2.5.] (영문)

마지막으로 EgoCube.IISWebAdmin 컴포넌트의 모든 버전들은 최근에 발표된 Windows 2003 제품군에서는 아직 테스트되지 않았다는 점을 미리 밝혀둔다. 따라서, 이에 해당하는 운영 체제에서는 올바른 동작을 보장하지 않는다는 점에 유의하기 바란다.

기존 버전의 컴포넌트에서부터 제공해주던 메서드와 새로 추가된 메서드 전부를 포함한 전체 메서드들의 목록은 다음의 표와 같다. Public Method 표의 경우 메서드의 이름을 클릭하면 해당 메서드에 대한 설명으로 바로 이동이 가능하므로 참고하기 바란다. 물론 기존부터 제공되던 메서드들의 경우, 각각 위에서 소개한 기존의 글들로 이동하게 된다.

Public 메서드

Private 메서드

DeleteWebServer() 메서드

메서드의 이름을 보면 쉽게 짐작할 수 있겠지만 이 DeleteWebServer() 메서드는 구 버전에서부터 제공되고 있는 CreateWebServer() 메서드에 대응하여 지정한 가상 웹 서버를 IIS로부터 제거하고 그 실행 결과를 리턴해준다. 비록 메서드의 사용법은 간단하지만, 그 작업 내용이 시스템에 미치는 결과를 고려해본다면 사용시 상당한 주의가 요구되는 메서드라고 이야기할 수 있을 것이다. 다음은 이 메서드의 정확한 시그니처로서 그 구조 자체는 매우 간단한 편이다.

Public Function DeleteWebServer(WebServerIndex As Integer,
                Optional WebServerName As String = "") As Boolean

모두 두 개의 인자가 선언되어 있는데, WebServerIndex 인자는 삭제하고자 하는 가상 웹 서버의 인덱스 값을 의미하고, WebServerName 인자는 삭제하고자 하는 가상 웹 서버가 설정된 웹 서버의 NetBIOS 이름으로, 이 인자가 생략되는 경우 현재 컴포넌트가 실행되고 있는 웹 서버의 NetBIOS 이름이 사용된다. 혹시 지금 이 글을 읽고 계시는 분들 중에서 가상 웹 서버의 인덱스 값이 무엇인지 모르시는 분들이 계시다면 필자의 이전 글들을 참고하기 바란다.

다음의 샘플 코드에서 DeleteWebServer() 메서드의 실제 사용법을 확인해 볼 수 있다. 이 샘플 코드는 현재 컴포넌트가 실행되고 있는 서버에서 서비스되고 있는 IIS 상에서 인덱스 값이 3인 가상 웹 서버를 제거하고 작업이 성공하면 True를, 실패하면 False를 리턴하거나 경우에 따라서는 오류를 발생시킨다. 만약, 스스로 생각하기에 가상 웹 서버의 인덱스 값에 대한 이해가 부족하다고 생각된다면, 혹시나 테스트 목적으로라도 절대 인덱스 값 1번이나 2번 가상 웹 서버를 대상으로는 이 코드를 실행하지 말 것을 권장한다.

왜냐하면 기본 설정을 사용해서 IIS를 설치한 경우 '기본 웹 사이트'에 인덱스 값 1 번이, '관리 웹 사이트'에 인덱스 값 2 번이 할당되기 때문에, 인덱스 값 1번이나 2번 가상 웹 서버를 대상으로 DeleteWebServer() 메서드를 테스트한다면 자칫 IIS를 다시 설치해야 하는 원치 않는 경우가 발생할 수도 있기 때문이다. 반드시 이 점을 주의하면서 테스트하기 바란다.

<%
  
  '******************************************************
  '*
  '* 지정한 인덱스 값의 가상 웹 서버를 제거한다.
  '*
  '******************************************************

  Dim oIISAdmin

  Set oIISAdmin = Server.CreateObject("EgoCube.IISWebAdmin")
  oIISAdmin.DeleteWebServer(3)
  Set oIISAdmin = Nothing
  
%>

만약, 현재 컴포넌트가 실행되고 있는 서버가 아닌 네트워크의 다른 서버에서 서비스되고 있는 IIS 상의 임의의 가상 웹 서버를 제거하고자 한다면, 위의 코드에서는 생략된 두 번째 인자에 해당 서버의 NetBIOS 이름을 입력하면 된다. 물론, 이 경우에는 작업에 필요한 권한 설정이 적절히 제공되야 한다.

그리고, 위의 샘플 코드 역시도 올바른 권한 설정없이 ASP 코드만 그대로 복사해서 테스트 프로그램을 작성한 다음 웹 브라우저를 사용하여 실행시키면 'EgoCube (0x800A0046) 사용 권한이 없습니다.' 라는 오류가 발생하면서 정상적으로 동작을 하지 않는데, 그 원인과 해결 방법에 대해서는 이미 여러 차례에 걸쳐서 설명했지만 이 자리를 빌어서 다시 한 번 간략히 추가 설명을 드리도록 하겠다.

결론부터 얘기하자면 이 오류는 IUSR_[MachineName] 계정의 권한과 메타베이스에 접근이 허락된 계정간의 권한 격차 때문에 발생하는 문제로서, 관리자 그룹에 속한 계정으로만 접근과 수정이 가능한 IIS의 메타베이스를 Guest 그룹에 속한 IUSR_[MachineName] 계정을 사용해서 접근하려고 하기 때문에 발생하는 것이다. 이 오류를 해결하는 가장 간단하면서도 확실한 방법은 COM+ 서비스의 역할 기반 보안 기능을 활용하는 것인데 그 구체적인 방법에 대해서는 다음에 링크된 문서들을 참고하기 바란다. 그리고, 이 문서들 중 첫 번째 글은 필자가 약 3년쯤 전에 작성한 것으로 최근의 글은 아니라는 점도 어느 정도는 염두에 두기 바란다.

• ASP와 VB 컴포넌트를 이용한 IIS 관리 자동화
• COM+의 역할 기반 보안(Role-Based Security)과 ASP에서 컴포넌트 사용하기

그러나, 이 샘플 코드를 활용하여 ASP 프로그램을 작성해서 사용하는 것이 아니라, 클라이언트에서 실행되는 응용 프로그램을 작성하는 경우라면 이러한 후속 조치는 더 이상 필요가 없어진다. 왜냐하면 그런 경우에는 현재 로그인한 사용자의 권한에 모든 작업 권한이 종족되기 때문이다. 물론 원한다면 클라이언트 응용 프로그램에서도 COM+ 서비스의 역할 기반 보안을 설정하여 사용할 수는 있으나 그다지 보편적인 상황은 아니라고 봐도 무방하다.

일단 위의 글들을 참고로 해서 COM+ 서비스의 역할 기반 보안 설정을 올바르게 마쳤다면, 반드시 서비스 관리 도구에서 IIS Admin 서비스를 중지시켰다가 다시 재시작하여 IIS Admin 서비스와 그 종속 서비스들을 초기화해야만 한다. 그 이유는 일단 IIS Admin 서비스 프로세스에 In-Proc 형태로 로드된 컴포넌트는 서비스를 재시작하기 전까지는 서비스의 프로세스 메모리에 인스턴스가 그대로 남아있기 때문이다.

If Request.ServerVariables("LOGON_USER") = "" Then
    Response.Status = "401 Authorization Required"
    Response.End
End If

CreateVirtualDir() 메서드와 DeleteVirtualDir() 메서드

이 두 메서드는 가상 디렉터리를 생성하거나 제거한다. 그리고, 그 정확한 시그니처는 각각 다음과 같다. 메서드의 실제 사용법은 생각보다는 매우 간단한 편인데 사용법을 알아보기에 앞서 가상 디렉터리라는 개념에 대해서 잠시 짚고 넘어가기로 하겠다.

Public Function CreateVirtualDir(VDirName As String,
                FullPath As String,
                WebServerIndex As Integer,
                Optional VDirParentsPos As String = "",
                Optional WebServerName As String = "",
                Optional Applevel As Integer = -1) As Boolean
                
Public Function DeleteVirtualDir(VDirName As String,
                WebServerIndex As Integer,
                Optional VDirParentsPos As String = "",
                Optional WebServerName As String = "") As Boolean

가상 디렉터리(Virtual Directory)라는 단어의 의미는 단순하게 IIS 에서 설정되고 웹 브라우저로 접근이 가능한 임의의 디렉터리에 대한 별칭이라는 뜻으로 이해되는 것이 일반적이다. 예를 들어서 웹 루트 디렉터리의 하위에 실제로 존재하는 디렉터리가 가상 디렉터리로 설정된다던가, 웹 루트 하위가 아닌 다른 드라이브의 임의의 폴더나 심지어는 네트워크 상의 다른 파일 서버의 공유 폴더가 특정 가상 웹 서버 하위의 가상 디렉터리로 설정이 된다던가 하는 식이다.

그러나, 가상 디렉터리는 단순히 이런 역할말고도 웹 응용 프로그램 설정의 단위가 되기도 하는데, 그런 이유로 모든 가상 디렉터리는 웹 응용 프로그램 설정이 된 가상 디렉터리와 웹 응용 프로그램 설정이 되지 않은 가상 디렉터리로 구분이 가능하다. 심지어 이 두 가지 종류의 가상 디렉터리는 인터넷 서비스 관리자에서 표현되는 아이콘부터가 서로 다른데, 양자 간의 미묘한 차이점을 정확하게 이해하지 못하면 IIS의 보다 깊은 특성을 파악하는데 상당한 어려움을 느끼게 될 것이라는 것이 필자의 사견이다.

1. 일반 폴더는 아이콘으로 표현된다.
2. 웹 응용 프로그램 설정이 되지 않은 순수한 가상 디렉터리는 아이콘으로 표현된다.
3. 웹 응용 프로그램 설정이 된 가상 디렉터리는 아이콘으로 표현된다.

이런 사실은 각각의 가상 디렉터리들이 단순히 아이콘이 틀리다는 것 이상의 무언가 특성의 차이가 존재한다는 점을 반증한다. 평범한 형태의 일반 폴더를 제외한다면 나머지 두 가상 디렉터리들간의 근본적인 차이점은 결국 웹 응용 프로그램이 설정되었는지 여부에 따라 좌우되는데, 사실 이는 단순히 IIS뿐만 아니라 COM+ 서비스를 아우르는 상당히 광범위한 영역을 포괄하는 내용으로, 이 자리에서 깊게 설명하기에는 상당히 부담이 되는 수준과 분량이 요구되는 주제다. (단적으로 웹 응용 프로그램 설정이 된 가상 디렉터리의 아이콘이 COM+ 서비스의 COM+ 응용 프로그램의 아이콘과 완전히 똑같다는 점에 주목하기 바란다.) 그러므로, 일단 본문에서는 CreateVirtualDir() 메서드와 DeleteVirtualDir() 메서드를 설명하는데 필요한 내용들만 다루고 해당 주제에 관해서는 별도의 글을 준비하는 것으로 하도록 하겠다.

가상 디렉터리에 설정되는 웹 응용 프로그램은 가상 웹 서버 루트에 설정되는 웹 응용 프로그램과 그 내용과 작용, 그리고 본질이 완벽하게 동일한 것으로서 아래의 그림에서 일부나마 그 사실을 직접 눈으로 확인할 수 있을 것이다. 이 화면은 필자가 글의 설명을 돕기 위해서 임시로 필자의 머신에 존재하는 cubeboard 라는 폴더를 가상 디렉터리로 설정하고 웹 응용 프로그램을 구성한 모습이다. ASP 프로그래머라면 거의 날마다 보고 있을 화면이겠지만 그 속에 감춰진 의미는 그리 간단하지가 않은 것이다.

아무런 가상 디렉터리나 비교 대상으로 삼아 디렉터리 속성 탭에서 구성(G)... 버튼을 눌러서 각각의 세부 설정 항목들을 비교해보면, 응용 프로그램 보호와 관련된 기본 항목 뿐만이 아니라 ISAPI 응용 프로그램 관련 설정, 세션 상태 설정, 버퍼링 상태 설정, 디버깅 관련 설정 등등 모든 설정 항목들이 가상 웹 서버 루트에 설정되는 웹 응용 프로그램과 동일하다는 사실을 확인할 수 있는데, 어떤 의미에서 이것은 너무나도 당연한 일이다. 왜냐하면, 사실 가상 웹 서버에 설정되는 웹 응용 프로그램도 사실은 가상 웹 서버 그 자체에 설정되는 것이 아니라 내부적으로는 가상 웹 서버의 루트 가상 웹 디렉터리에 설정되는 것이기 때문이다. 사실, 이런 점들은 인터넷 서비스 관리자가 보여주는 피상적인 모습만으로는 속속들이 알아내기 힘든 내용들이다.

아무튼 지금까지의 설명에서 확실하게 알 수 있는 내용 한 가지는 문제의 핵심이 웹 응용 프로그램이라는 사실이다. 사실 ASP 프로그래밍을 오래 한 분들 중에서도 웹 응용 프로그램이란 용어 자체를 모르거나 그 의미에 대해서 정확하게 파악하지 못하고 계시는 분들이 많은 것으로 알고 있다. 그냥 선험적 경험에 의해서 어떤 설정을 하면 어떤 결과가 나온다는 것만 알고 계시는 분들도 역시 적지 않은 편이다.

그러나, 다시 한 번 강조하지만 웹 응용 프로그램이라는 개념을 정확하게 알지 못하면 IIS의 고급 기능들에 대해서는 파악이 불가능하다. 가령, 이를 이해하지 못하면 Windows Server 2003에서 제공하는 IIS 6.0의 Worker Preocess Isolation Mode와 IIS 5.0 Isolation Mode간의 차이점을 이해하는 것은 절대 불가능하다. 그러나, 이미 앞에서도 얘기했듯이 본문에서는 이 주제에 관해서는 깊게 다루지 않을 것이다. 필자 스스로도 괜히 얘기만 꺼내 놓고서 마무리를 짓지 않는 것만 같아서 기분이 깔끔하지 않기는 하지만, 지금 이야기를 시작하면 도무지 이 글내에서는 수습할 자신이 없으니 별다른 방법이 없다.

그러면, 다시 본론으로 되돌아와서 CreateVirtualDir() 메서드와 DeleteVirtualDir() 메서드의 실제 사용법에 관해서 알아보도록 하자. 지금까지 얘기한 것처럼 가상 웹 서버를 생성할 때 뿐만 아니라 가상 디렉터리를 생성할 때도 웹 응용 프로그램에 대한 고려는 반드시 감안되어져야만 한다. 따라서, CreateVirtualDir() 메서드로 생성할 수 있는 가상 디렉터리의 종류는 다음과 같이 모두 네 종류로 분류가 가능하다.

1. 웹 응용 프로그램 설정이 되지 않은 순수한 가상 디렉터리
2. 웹 응용 프로그램 설정이 된 가상 디렉터리 → 응용 프로그램 보호 수준 : 낮음(IIS 프로세스)
3. 웹 응용 프로그램 설정이 된 가상 디렉터리 → 응용 프로그램 보호 수준 : 보통(풀링됨)
4. 웹 응용 프로그램 설정이 된 가상 디렉터리 → 응용 프로그램 보호 수준 : 높음(격리됨)

이 중에서 3번의 경우는 IIS 4.0에서는 지원되지 않으므로 참고할 필요가 있다. 그리고, 다른 관점에서 생각해본다면 2번부터 4번까지는 하나의 범주로 구분하는 것이 논리적으로 더 맞다고 느낄수도 있을 텐데, 굳이 이런식으로 응용 프로그램 보호 수준에 따라서 세부적으로 하나씩 구분을 해 놓은 이유는, 역시 앞에서 설명한 웹 응용 프로그램이라는 관점에서 생각해 볼 때 각각의 응용 프로그램 보호 수준에 따라 내부적으로 처리되는 방법이 판이하게 다르기 때문에 이를 구분하기 위한 것이다.

다음의 샘플 코드는 임의의 폴더인 c:\Temp\sample이라는 폴더를 기본 웹 사이트(인덱스 번호 1)의 홈 디렉터리 바로 하위에 VirtualDir이라는 이름의 가상 디렉터리로 생성하는 예제다. 이 샘플 코드에서는 웹 응용 프로그램은 생성하지 않으며 만약 지정된 경로에 해당 폴더가 실제로 존재하지 않는다면 컴포넌트가 가상 디렉터리를 생성하기 전에 내부적으로 FileSystemObject 개체를 이용해서 해당 폴더를 바로 만들어 버린다.

그런데, 이 경우 한 가지 주의해야만 하는 사실은 FileSystemObject 개체로부터 제공되는 폴더 생성 기능은 한 번에 한 단계 밖에는 폴더를 생성하지 못한다는 점이다. 즉 c: 드라이브에 Temp라는 하위 폴더가 이미 존재하고 있는 경우에는 아무런 문제도 없이 c:\Temp\sample라는 폴더가 생성되지만, 만약 Temp 폴더조차도 존재하지 않는 상황이라면 c:\Temp\sample폴더는 물론이려니와 가상 디렉터리 역시도 생성되지 않은채 프로그램에서는 'EgoCube (0x800A004C) 경로를 찾을 수 없습니다.'라는 오류가 리턴될 것이다. 이는 컴포넌트 자체의 오류가 아니므로 참고하기 바란다.

<%
  
  '******************************************************
  '*
  '* VirtualDir 이라는 이름으로 웹 응용 프로그램이 설정되
  '* 지 않은 가상 디렉터리를 생성한다.
  '*
  '******************************************************

  Dim oIISAdmin
  Dim bResult
    
  Set oIISAdmin = Server.CreateObject("EgoCube.IISWebAdmin")
  bResult = oIISAdmin.CreateVirtualDir("VirtualDir", "c:\Temp\sample", 1)
  Set oIISAdmin = Nothing
  
%>

비교적 간단한 코드로, 첫 번째 인자는 생성하고자 하는 가상 디렉터리의 이름을 뜻한다. 당연히 중복되는 이름이 이미 존재하고 있다면 오류가 발생할 것이다. 두 번째 인자는 가상 디렉터리에 매핑될 실제 폴더의 전체 경로고, 마지막 세 번째 인자는 언제나처럼 가상 디렉터리가 생성될 가상 웹 서버의 인덱스 값이다.

이번에는 방금전의 샘플 코드에서는 사용되지 않은 나머지 세 개의 옵션 인자들에 대해서 알아보자. 먼저, 네 번째 인자인 VDirParentsPos는 가상 디렉터리가 생성될 위치를 결정한다. 예를 들어서, 위의 샘플 코드에서는 이 인자가 생략되었으므로 가상 웹 서버 루트의 바로 하위에 새로운 가상 디렉터리가 생성되었다. 그러나, 때로는 가상 웹 서버 루트의 바로 하위가 아닌 그 하위에 위치한 임의의 가상 디렉터리나 폴더의 하위에 새로운 가상 디렉토리를 만들어야만 하는 경우가 생기는데 바로 그런 경우에 이 인자를 사용할 수 있다. 다음은 위의 샘플 코드에서와 동일한 조건을 만족하고 가상 디렉터리를 생성하고자 하는 위치가 가상 웹 서버 루트 바로 하위가 아닌 Scripts 가상 디렉터리의 하위인 경우의 샘플 코드이다.

<%
  
  '******************************************************
  '*
  '* VirtualDir 이라는 이름으로 웹 응용 프로그램이 설정되
  '* 지 않은 가상 디렉터리를 Scripts 가상 디렉터리 하위에
  '* 생성한다.
  '*
  '******************************************************

  Dim oIISAdmin
  Dim bResult
    
  Set oIISAdmin = Server.CreateObject("EgoCube.IISWebAdmin")
  bResult = oIISAdmin.CreateVirtualDir("VirtualDir", "c:\Temp\sample", 1, "/Scripts/")
  Set oIISAdmin = Nothing
  
%>

따라서, 가상 웹 서버 루트 하위의 Scripts 가상 디렉터리 하위의 VirtualDir 가상 디렉터리 하위에 새로운 가상 디렉터리인 VirtualDirNew를 생성하고 싶다면 위의 코드에서 VDirParentsPos 인자의 입력값을 다음과 같이 수정하면 된다.

bResult = oIISAdmin.CreateVirtualDir("VirtualDirNew", "c:\Temp\sample", 1, "/Scripts/VirtualDir/")

이 때 경로의 구분자로는 / 문자가 사용되고 맨 앞과 맨 뒤의 / 문자는 컴포넌트가 내부적으로 제거하므로 개발자의 취향에 따라 입력해도 되고 또는 입력하지 않아도 상관이 없다.

다섯 번째 WebServerName 인자는 언제나처럼 작업 대상이 되는 가상 웹 서버가 위치한 웹 서버의 NetBIOS 이름으로, 이 인자가 생략되는 경우 현재 컴포넌트가 실행되고 있는 웹 서버의 NetBIOS 이름이 사용된다. 따라서, 네트워크상에 존재하는 WWW_SERVER_01이라는 가상의 서버상에서 운영되고 있는 기본 웹 사이트의 하위에 첫 번째 샘플 코드에서와 동일한 조건의 가상 디렉터리를 생성하고자 한다면 WebServerName 인자값을 다음과 같이 추가 또는 수정해주면 된다. 그리고, 이 경우에 해당 작업에 필요한 적절한 권한 설정이 요구되는 것은 물론이다.

bResult = oIISAdmin.CreateVirtualDir("VirtualDir", "c:\Temp\sample", 1, "", "WWW_SERVER_01")

가장 마지막 여섯 번째 Applevel 인자는 새로 생성하고자 하는 가상 디렉터리의 웹 응용 프로그램 생성 유무 그 자체와 웹 응용 프로그램의 보호 수준을 결정한다. 즉 인자값으로 0 이 입력되면 웹 응용 프로그램의 보호 수준이 '낮음(IIS 프로세스)' 로 설정되고, 1 이 입력되면 '높음(격리됨)' 으로, 그리고 2 가 입력되면 '보통(풀링됨)' 으로 설정되며, 그 외의 다른 값이 입력되거나 생략되는 경우에는 지금까지의 샘플 프로그램들에서처럼 웹 응용 프로그램이 아예 생성되지 않는다.

그리고, 이미 앞에서도 한 번 얘기했지만 IIS 4.0 에서는 '보통(풀링됨)' 보호 수준이 지원되지 않으므로 인자값으로 2를 입력해도 웹 응용 프로그램의 보호 수준은 '낮음(IIS 프로세스)'으로 설정된다. 이는 MTS나 COM+ 서비스와 각각의 IIS 버전 간의 기능 제공 차이로 인해서 발생하는 것으로서 이 부분에 대해서 좀 더 깊게 이해하고자 하시는 분은 MSDN에서 AppCreate() 메서드와 AppCreate2() 메서드에 대해서 검색해보기 바란다.

따라서, 첫 번째 샘플 코드에서처럼 c:\Temp\sample이라는 폴더를 기본 웹 사이트(인덱스 번호 1)의 홈 디렉터리 바로 하위에 VirtualDir이라는 이름의 가상 디렉터리로 생성하면서, 그 보호 수준이 '보통(풀링됨)'으로 설정된 웹 응용 프로그램을 생성하고자 하는 경우에는 다음과 같은 코드를 사용하면 된다.

<%
  
  '******************************************************
  '*
  '* VirtualDir 이라는 이름으로 보호 수준이 '보통(풀링됨)'
  '* 으로 설정된 웹 응용 프로그램이 설정된 가상 디렉터리를
  '* 생성한다.
  '*
  '******************************************************

  Dim oIISAdmin
  Dim bResult
    
  Set oIISAdmin = Server.CreateObject("EgoCube.IISWebAdmin")
  bResult = oIISAdmin.CreateVirtualDir("VirtualDir", "c:\Temp\sample", 1, "", "", 2)
  Set oIISAdmin = Nothing
  
%>

비록 지금까지 설명은 길었지만 간단히 요약해보면 CreateVirtualDir() 메서드의 사용법도 상당히 간단한 편이라고 말할 수 있을 것이다. 그리고, 필자의 사견으로는 결국 마지막 샘플 코드와 같은 패턴으로 사용되는 경우가 가장 많을 것이라고 생각한다.

이제 역으로 이렇게 생성한 가상 디렉터리를 DeleteVirtualDir() 메서드를 사용해서 제거하는 방법에 대해서 알아본다. 이는 가상 디렉터리를 생성하는 것보다도 훨씬 더 쉬운 편인데, 사용되는 인자의 이름이라던가 인자의 의미가 지금까지 설명한 CreateVirtualDir() 메서드 인자들의 그것과 같으므로 각각의 인자들에 대해서는 별도로 설명을 하지 않도록 하겠다. 먼저 다음의 샘플 코드를 살펴보도록 하자.

<%
  
  '******************************************************
  '*
  '* 기본 웹 사이트의 VirtualDir 가상 디렉터리를 제거한다.
  '*
  '******************************************************

  Dim oIISAdmin
  Dim bResult
    
  Set oIISAdmin = Server.CreateObject("EgoCube.IISWebAdmin")
  bResult = oIISAdmin.DeleteVirtualDir("VirtualDir", 1)
  Set oIISAdmin = Nothing
  
%>

이 샘플 코드는 직전의 샘플 코드로 생성한 VirtualDir이라는 이름의 가상 디렉터리를 제거하는 코드다. 만약의 경우를 대비해서 실제 폴더는 삭제하지 않으며 IIS상의 가상 디렉터리 설정만을 해제하므로, 필요한 경우 별도의 ASP 코딩을 통해서 실제 폴더를 제거하는 작업이 요구된다. 그리고, 역시 위의 코드에서는 생략된 세 번째 인자 VDirParentsPos와 네 번째 인자 WebServerName를 사용해서 다양한 위치에 존재하고 있는 가상 디렉터리를 제거할 수가 있는데, 이 기능들은 여러분들이 한 번 직접 테스트해보기 바란다.

마지막으로 지금까지 살펴본 EgoCube.IISWebAdmin 컴포넌트의 기능들을 실제 개발 환경에서 적용할 수 있는 부분들에 대해서 한 번 생각해보고 글을 마무리하기로 하자. 사실, 가상 웹 서버나 가상 디렉터리를 생성하거나 제거, 또는 관리할 수 있는 EgoCube.IISWebAdmin 컴포넌트의 기능들 대부분은 일반적인 ASP 프로그래밍 환경에서는 그다지 사용될 일이 없는 기능들이다. 그러나, 간혹 특수한 상황을 마주하게 되는 경우, 이와 같은 기능들 말고서는 달리 대안이 없는 경우가 있는데, 예를 들자면 설치 프로그램의 설치 과정중 IIS 자체의 제어나 가상 웹 서버 또는 가상 디렉터리의 설정이 필요한 경우도 그 대표적인 사례의 하나라고 말할 수 있을 것이다.

즉, 설치 작업의 대상이 되는 IIS에 새로운 가상 웹 서버나 가상 디렉터리를 생성하는 등의 기본적인 작업 외에도 사용자가 지정한 가상 웹 서버에 특수한 MIME Type 설정을 추가하는 작업이라던가 서버 바인딩 설정을 조정하고 특정 웹 응용 프로그램에 ISAPI 응용 프로그램 매핑 설정을 추가하는 등의 작업이 그것이다. 이런 작업들이 요구되는 경우, 꼭 EgoCube.IISWebAdmin 컴포넌트 그 자체에서 제공하는 기능이 아니더라도 이를 활용한 ADSI 프로그래밍이 많은 도움이 될 수 있다. 단적인 사례로 방금 예를 든 작업들은 필자가 머리속에서 아무렇게나 생각나는 대로 예를 든 것이 아니라, 실제로 사용자분들이 게시판을 통해서 필자에게 질문한 사항들을 정리한 것으로 이는 해당 기술이 실무에서도 요구되고 있는 것임을 증명해준다. 이런 내용들에 대해 관심이 있는 분들은 Active Directory Service Interface 게시판의 질문과 답변들을 참고하기 바란다.

그러나, 필자는 위와 같은 사례들보다 EgoCube.IISWebAdmin 컴포넌트가 더욱 유용하게 사용될 수 있는 대표적인 경우는 Windows 기반의 웹 호스팅 시스템을 구축하거나 가상 디렉터리를 이용한 약간은 특수한 형태의 커뮤니티를 사용자들에게 서비스해주고자 할 때라고 생각한다. 전통적인 의미의 웹 호스팅 서비스는 물론이려니와 요즘 상당히 보편적으로 서비스되고 있는 http://User_ID.Domain_Name/ 형식의 도메인 네임 제공 서비스라던가 가상 디렉터리를 활용한 http://Domain_Name/User_ID/ 형식의 사용자 커뮤니티를 제공한다던지 하는 경우도 역시 훌륭한 사례라고 말할 수 있다.

비단 사용자들에게 제공되는 부분들뿐만 아니라, 서비스 관리자가 서비스로부터 발생되는 작업 요구 사항들을 처리하고 관리하는 부분에 있어서도 상당한 편리함과 효율성을 제공해 줄 수 있는데, 기타 잡다한 작업들을 자동화할 수 있으며 네트워크상에 방대하게 산재되어 있는 각각의 IIS와 가상 웹 서버들에 대한 모니터링 시스템을 기업의 입맛에 적합하도록 최적화하여 구축하는 것이 가능하며, 언제나 즉각적인 대응을 가능하도록 해준다. 물론 엄밀히 말하자면 이는 EgoCube.IISWebAdmin 컴포넌트의 기능이라기 보다는 ADSI 자체가 제공해주는 기능이라고 얘기하는 것이 맞겠지만 EgoCube.IISWebAdmin 컴포넌트를 사용해서 작업을 보다 효율적으로 진행할 수도 있을 것이다.