Partager via

Administering IIS Programmatically

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1

Graphical user interfaces (GUIs) on your computer—such as Internet Information Services (IIS) Manager, Computer Management Console, Control Panel, or Windows Explorer—help you manage and configure your settings. However, if you manage systems frequently or access large amounts of data on numerous servers, then using a collection of GUIs can be time consuming. In these cases, it is faster to use command-line scripts that can change single or multiple systems programmatically.

For example, using IIS Manager to add a script mapping to 20 Web servers will take many mouse clicks and key strokes. However, using a command-line script that takes an input file containing the names of your Web servers and the name of the property you want to change, you can make all of these changes from one server with a single command.

IIS 6.0 comes with three programmatic interfaces (also called providers), Windows Management Instrumentation (WMI), Active Directory Service Interface (ADSI), and Administrative Base Objects (ABO). Because the ABO interface can only be accessed from a compiled application, ABO is only discussed in the IIS SDK.

By using the WMI and ADSI providers, you can efficiently monitor the IIS metabase, and access and configure settings from within a command-line script or compiled application.

The IIS WMI Provider

Windows Management Instrumentation (WMI) is a technology that allows administrators to programmatically manage and configure the Windows operating system and Windows applications. Beginning with IIS 6.0, IIS includes a WMI provider that exposes programming interfaces that can be used to query and configure the IIS metabase.

The IIS ADSI Provider

The IIS ADSI provider exposes COM Automation objects that you can use within command-line scripts, ASP pages, or custom applications to change IIS configuration values stored in the IIS metabase. IIS ADSI objects can be accessed and manipulated by any language that supports automation, such as Microsoft® Visual Basic® Scripting Edition (VBScript), Microsoft JScript®, Perl, Microsoft Active Server Pages (ASP), Visual Basic, Java, or Microsoft C++.

Comparing the ADSI and the IIS WMI Providers

The following table compares the architecture and features of the IIS ADSI provider with those of the IIS WMI provider.

Issue IIS ADSI provider IIS WMI provider

Query capabilities

No. ADSI has no provision for queries.

Yes. By querying on metabase key types, the IIS WMI provider returns only the data you need.

Object model and access routes

COM: Scripts and programs.

COM: Scripts, programs, and UI tools; for example, the WMI Object Browser.

Extensible schema

Yes. ADSI provider supports metabase schema extensions.

No. The IIS WMI provider can return existing schema extensions, but cannot extend the metabase schema.

Association or containment of related data

Properties are related to IIS metabase keys by containment.

You can use the ADSI container object methods of the IIS Admin Objects to manipulate keys in the IIS metabase. You can create, delete, and move keys by creating, deleting, and moving IIS Admin Objects within container objects. You can also enumerate contained objects, such as virtual directories or servers with container object methods. ADSI supports property inheritance.

Properties are related to IIS metabase keys by containment or by association. Also, in conjunction with other providers, WMI supports associations with managed objects not in the metabase.

An association in WMI describes a relationship between classes and is in itself defined by a class. This powerful concept allows management information about an entire system of associated components to be viewed and traversed for tasks such as troubleshooting. Navigating associations to other classes is not limited by containment.