IIS 6.0, Getting Information Using WMI

You can execute every script by saving each of them individually as text files with the “.vbs” extension and execute through the WSH engine (like wscript.exe or cscript.exe) from your MS-DOS prompt.  Note that I tested all the scripts only with Windows Server 2003 Standard Edition.  

Internals of IIS

I don’t think there exists any web developer who doesn’t know IIS.  It is one of the most famous web servers available on the market.  It became quite famous with version 4.0 on Windows NT.  It was later upgraded to 5.0 on Windows 2000 and further enhanced to 6.0 on Windows 2003.  Version 7.0 is getting ready with Windows Vista!  Before proceeding with IIS 6.0, I would like to have a discussion about the internals of IIS 5.0.

There was only one main process (or service) in IIS 5.0, represented by the executable inetinfo.exe that was designed to function as the main Web server process. This generally redirects requests to one or more out-of-process applications that are running within the “dllhost.exe”. The Inetinfo.exe is considered to be the master process through which each request must “penetrate” regardless of isolation mode.

IIS 5.0 mainly has three isolation modes namely:

• In-Process,
• Out-of-process
• Pooled.

When considering the ”In-Process” mode, all the applications run in the same process as that of the Web server (inetinfo.exe). The IIS 5.0 default mode is “pooled,” in which the Web server (Inetinfo.exe) runs in its own process and all other applications will run in one single-pooled process (dllhost.exe). You can set high-priority applications to run as Isolated, which creates another instance of dllhost.exe (which also burdens RAM).

Even though this out-of-process isolation allows you to increase the fault-tolerance of your Web server, it is slow in terms of performance. The Pooled mode is the best performance/isolation tradeoff, but there is only one pool on a server and all pooled applications must use the same pool.

What is new in IIS 6.0?

IIS 6.0 is the next generation of Web server available in the Windows Server 2003 platform. IIS 6.0 obviously provides several enhancements over IIS 5.0 that are mainly intended to increase reliability, manageability, scalability, and security. IIS 6.0 is a key component of the Windows Server 2003 application platform, using which you can develop and deploy high performance ASP.NET Web applications, and XML Web Services.  XML Web Services can be natively deployed and we can even convert IIS6.0 to be UDDI directory!

IIS 6.0 has been totally redesigned with a new request processing architecture that has the benefits of high isolation without incurring the out-of-process cost, as well as much higher levels of reliability and scalability.  Let us go through some of the main components of IIS6.0.

• HTTP.SYS
• Web Administration Service
• Application Pool
• Worker Process

HTTP.SYS is a kernel-mode (OS level) HTTP listener that listens for incoming requests and queues those requests up on the appropriate queue. Kernel mode support is not available in IIS 5.0.  Each request will be serviced by one application pool. An application pool in IIS 6.0 can contain one or more applications.

Web Administration Service is a user-mode configuration and process manager. The Web Administration Service component performs mainly Configuration and Process Management. When the Web server is first initialized, the Web Administration Service configures HTTP.SYS and the application pools (more about it later). It is also responsible for monitoring and controlling the lifetime of the worker processes (more about this later).

Application pools are used to manage a set of websites and applications. IIS 6.0 can support up to 2,000 application pools per server, and there can be multiple application pools operating at the same time. Application pools are separated from other application pools by Windows Server 2003 process boundaries. Therefore, an application in one application pool is not affected by applications in other application pools, and an application request cannot be routed to another application pool while being serviced by the current application pool.

A worker process services requests for the websites and applications in an application pool. All Web application processing, including loading of ISAPI filters and extensions, as well as authentication and authorization, is done by a new WWW service DLL, which is loaded into one or more host worker processes. The worker process executable is named W3WP.EXE.

Can we retrieve IIS information using WMI?

Why not? As WMI is also meant for system administration, obviously it boasts very good support for IIS.  To find more information about WMI, you can refer to my previous articles at this website.  To work with IIS and WMI together, we need to work with the classes existing in the “root\MicrosoftIISv2” namespace.  This is a very important point to remember when working with WMI for IIS.

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\MicrosoftIISv2")
Set colItems = objWMIService.ExecQuery( _
    "SELECT * FROM IIsWebInfo",,48)
For Each objItem in colItems
    Wscript.Echo objItem. MajorIIsVersionNumber & " -->: " & objItem. MinorIIsVersionNumber
Next

Within the above example, I am working with a class “IIsWebInfo” available in the “\\root\MicrosoftIISv2” namespace.  “IIsWebInfo” mainly contains all information regarding version, status, install date, and so on.

Can we know, whether IIS is running or not using WMI? Certainly.  Not only that, we can even retrieve further information about IIS (if it is still running) by using the following script:

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\MicrosoftIISv2")
Set colItems = objWMIService.ExecQuery( _
    "SELECT * FROM IIsWebService",,48)
For Each objItem in colItems
    Wscript.Echo "DisplayName: " & objItem.DisplayName
    Wscript.Echo "Name: " & objItem.Name
    Wscript.Echo "PathName: " & objItem.PathName
    Wscript.Echo "Started: " & objItem.Started
    Wscript.Echo "State: " & objItem.State
    Wscript.Echo "Status: " & objItem.Status
    Wscript.Echo "SystemName: " & objItem.SystemName
Next

Within the above example, I am working with a class “IIsWebService” available in the “\\root\MicrosoftIISv2” namespace.  “IIsWebService” gives more in-depth information than “IIsWebInfo”.

Playing with Virtual directories and Web applications

Let us consider that I would like to retrieve all Virtual directories existing in my local IIS web server.  You can simply use the following WMI script and get it executed through WSH at the command prompt:

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\MicrosoftIISv2")
Set colItems = objWMIService.ExecQuery( _
    "SELECT * FROM IIsWebVirtualDir",,48)
For Each objItem in colItems
    Wscript.Echo objItem.AppRootEcho & " --> " & objItem.Name
Next

Within the above example, I am working with a class “IIsWebVirtualDir” available in  the “\\root\MicrosoftIISv2” namespace.  “IIsWebVirtualDir” mainly contains all directories, which are termed Virtual Directories.  You can get plenty of other information using the same class.

If we wanted to know which web applications are currently running, along with their responsible application pools (as explained in second section), we can use the following script:

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\MicrosoftIISv2")
Set colItems = objWMIService.ExecQuery( _
    "SELECT * FROM IIsWebVirtualDirSetting",,48)
For Each objItem in colItems
    Wscript.Echo "Name: " & objItem.Name & " -> Pool: " & objItem.AppPoolId
Next

Within the above example, I am working with a class “IIsWebVirtualDirSetting” available in the “\\root\MicrosoftIISv2” namespace.  “IIsWebVirtualDirSetting” gets all the web settings or IIS settings for each and every Virtual Directory available in “IIsWebVirtualDir”.  The next example is also based on the same class.

If you wanted to check and see all the virtual directories allowed with directory access, you have the following script:

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\MicrosoftIISv2")
Set colItems = objWMIService.ExecQuery( _
    "SELECT * FROM IIsWebVirtualDirSetting",,48)
For Each objItem in colItems
        Wscript.Echo "Name: " & objItem.Name
 & " -> browsing Enabled: " & objItem.EnableDirBrowsing
Next

How about SMTP, POP3, FTP services in IIS?

Any IIS being used for production would generally have one or more of SMTP, POP3, or FTP services enabled.  WMI can still help us retrieve information even to that level. The main information about the “status” of those services can be known using the classes “IISSmtpService”, “IISFtpService” and “IISPOP3Service” classes respectively.  Let us consider a few more scripts with respect to those services.

Let us see if SMTP was enabled in IIS (using WMI).  The following is the code:

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\MicrosoftIISv2")
Set colItems = objWMIService.ExecQuery( _
    "SELECT * FROM IIsSmtpService",,48)
For Each objItem in colItems
    Wscript.Echo "Name: " & objItem.Name & " -> running: " & objItem.Started
Next

Let us see if FTP was enabled in IIS (using WMI).  The following is the code:

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\MicrosoftIISv2")
Set colItems = objWMIService.ExecQuery( _
    "SELECT * FROM IIsFtpService",,48)
For Each objItem in colItems
    Wscript.Echo "Name: " & objItem.Name & " -> running: " & objItem.Started
Next

Let us see if POP3 was enabled in IIS (using WMI).  The following is the code:

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\MicrosoftIISv2")
Set colItems = objWMIService.ExecQuery( _
    "SELECT * FROM IIsPop3Service",,48)
For Each objItem in colItems
    Wscript.Echo "Name: " & objItem.Name & " -> running: " & objItem.Started
Next

And that is that.