IIS Manager

Windows Server 2003

Internet Information Services 7.0 (IIS7) includes a new version of the IIS Manager (previously known as the Web Management Tool), updated to better support the power of IIS7. Some of the improvements in the IIS Manager include:

  • Consolidated management of IIS and ASP.NET applications.

  • The ability to run as a standalone application or within the Microsoft Management Console (MMC) as a MMC snap-in.

  • An improved UI that provides more consistency and better navigation and selection features. The UI includes a customized tree-view navigation pane with a command bar, breadcrumbs, and consolidated management of many types of information, including configuration data, content, run-time state, provider, and operation data.

  • The ability to delegate administrative rights (on a per-computer, Web-application, or Web-site basis) to users who do not have administrative rights to the local computer. This capability is made possible by two new features of IIS7: administrator lists and feature delegation.

  • The ability to administer both local and remote application servers. The IIS Manager supports forms, basic, and Windows authentication modes.

  • Better support for staging and Web farms.

  • Support of secure communications and the validation of configuration changes before they take effect.

  • Support for multiple versions of the Common Runtime Library (CLR), which is required for robust ASP.NET management.

The IIS Manager is built on Web Management Framework, which is composed of a set of standard modules built on the .NET Framework 3.0 managed classes. Web Management Framework provides developers with the following benefits:

  • Web servers, sites, and applications can be managed by calling into Web Management Framework.

  • Web Management Framework's extensible object model enables developers to add classes and properties that are managed alongside built-in types. Managerial processes built as Web services can be integrated into the IIS Manager (or another Web Management Framework-compatible tool).

  • Web Management Framework has client UI components that can be hosted within other applications and tools.

The following image shows the IIS Manager displaying the sites on the current Web server.


Web Management Framework was designed to support a distributed, client-server architecture built on the following primary components:

Web Management Framework Component


Web management client

The application that hosts the client UI (for example, the IIS Manager, MMC, or Visual Studio). Each client contains a connection manager that connects to the Web management server and manages the set of active connections.

Web management components

A collection of Web Management Framework objects that implement the client-side functionality and UI and allow for extensibility.

Web management server

A stand-alone instance of a Web server that is used solely for remote, delegated management. The client communicates with this server via HTTPS. It has the ability to operate in two modes: local only (the default) or local and remote.

Core Web server

The Web server that runs the sites and applications that are being managed. During the course of running, it accesses the content and provider data, and updates its runtime state, and generates operational data.

Web Management Framework was designed around the concept of a connection, which represents a single management session for a specific management unit: a specific application, a site, or the server under a specific version of CLR.

Each connection logically contains one or more modules, which represent the available set of management features and typically include associated client-side UI functionality. In general, the module code on the client does not interact directly with management configuration and information on the core Web server. Instead, all queries and modifications to management information are performed via calls to the associated module service.

A module service is a Web service that executes on the Web management server and is invoked by client modules to implement the associated management functionality. Each module service is associated with a module provider, which is a server-side entity that determines whether a specific module is enabled or disabled based on context information provided by the management client.

Management module providers can be selectively enabled or disabled for an application, site, or server. They are the basis of the extensibility model in the design structure. If a client does not have the executable for a specific module that has been enabled for the current connection, the client code will automatically be downloaded. This process forms the mechanism by which the client can be updated with newer versions of modules and extended with new modules.

The following diagram details how these concepts and architecture interact:


The Web Management Framework includes a client-side UI model based on a Web-browsing metaphor: functionality is modeled in the form of pages that can be navigated back and forth (for example, via links and the back and forward buttons). In addition to the browsing functionality, the UI is a task-oriented one, as opposed to property-oriented. Changes to the configuration and management information are primarily performed through tasks.

Features are implemented in the form of pages. A page is implemented as a UI control class that also implements the IModulePage interface. Pages and modules offer tasks by implementing Task Lists (with the TaskList class) and Task Items (with the TaskItem class) to allow the administrator to perform management activity. Modules register feature categories and features within them by using the IControlPanel service.

The environment offers a number of services for use by pages. These services are available via the IServiceProvider reference provided to the page during its initialization. For example, the Connection service represents the current connection associated with the management session, which enables creating Web service proxies, opening related connections, and so on.

The Web Management Framework API is divided into the following four portions:

  • The server defines the operation of the Web management server.

  • The client defines client-side portions, including the Web management clients and their components.

  • The hosting environment enables the core user interface and functionality contained within the client to be hosted in different shells, such as the IIS Manager and MMC.

  • The configuration portion enables limited configuration of the server, as well as the associated administrators.

The following sections list many of the primary public interfaces, classes, and enumerations available in these portions of Web Management Framework.

Bb756935.collapse_all(en-us,MSDN.10).gifServer Framework Resources

.NET Framework 3.0 Namespace







Encapsulates context information that is made available to both the module provider and module services. Provides information about the client (for example, name and the CLR version being used).




Acts as the base class for implementing new management (extension) modules. This class provides the current management context.


Acts as the base class for implementing management module providers, which supply information about a management module, including its module service type, the location of the management module code, and so on. These classes represent the main registration point for all features and should be registered in the administration.config file in the inetsrv directory.


Encapsulates information about a specific management module for use on the server, such as its name and associated service type.


Encapsulates information about a specific management module that is sent to the client, such as its name, associated service URL, and the assembly containing the module.


Encapsulates contextual information about the management unit currently being managed during the execution of a Web service method on a module service. This class is also used to retrieve configuration of the management unit.


Encapsulates contextual information about a server being managed, such as the computer name.


Encapsulates contextual information about an application being managed, such as the application name, its virtual path, and containing site.


Encapsulates contextual information about a site being managed.


Encapsulates a configuration loaded from an instance of ManagementUnit. This class allows access to configuration sections, abstracts of the various configuration files on the server (root web.config and iis.config), the update configuration, and so on.


Acts as the base class for implementing a type information generator, which generates information about types within an application domain representing the application being managed so that it can be marshaled back to the module service running in the default application domain.




Defines the various types of management units supported by the environment, such as application, site, and server.

Bb756935.collapse_all(en-us,MSDN.10).gifClient Framework Resources

.NET Framework 3.0 Namespace








Act as the interfaces, respectively, for a page and for a child page of the client UI for a connection. A child page is a page that is not directly navigable to (it does not appear in the control panel), but instead is navigated to from a page that does show up in the control panel.


Represents a module service that manages connections, including active, new, and serialized (favorites) connections.


Enables navigating between different pages within the user interface.


Enables access to and storing of per-user preferences.


Enables access to the available features in a connection and is used to generate the control panel UI. Each feature is mapped to a particular page.


Enables extension modules to register their functionality so they can be presented in an integrated manner in the appropriate context.




The base class for implementing the UI for the extension module client.


The class that exposes the functionality of the ModuleService derived class.





A set of classes that define characteristics for an instance of ModuleListPage.


The class for a connection, which represents an active management session.


A class that encapsulates, in a serializable form, information about a connection.



A class and delegate that support connection events.



A class and delegate that support navigation events.




Classes that support the task-based user interface and command processing architecture of Web Management Framework.




Defines behavior for an instance of ModuleListPage.

.NET Framework 3.0 Namespace







The base class for implementing a page of the client UI for a connection.


The base class for a module page that contains a listing.


The base class for a module page with dialog-like semantics.



Classes that support the task-based user interface and command processing architecture of Web Management Framework.

Bb756935.collapse_all(en-us,MSDN.10).gifHosting Framework Resources

.NET Framework 3.0 Interface




Identifies the host of a Web Management Framework. Each host will have a different implementation of this interface.



Launches the connection and logon UI of the host.



Enables Windows Forms-based hosts to launch the UI associated with service modules, such as dialogs, message boxes, and progress indicators.



Launches the help UI of the host.

The following steps describe how to introduce a new management feature using the extensibility mechanisms:

  1. Implement the core functionality of the extension in two parts, as a module service and a module provider.

    • The module service for the extension is implemented in a class derived from ModuleService. Implement the desired methods and properties and annotate the publicly accessible members with the ModuleServiceMethodAttribute class to expose their functionality.

    • The module provider is implemented in a class derived from ModuleProvider. Implement a GetModuleDefinition method to determine if the extension module is to be enabled or disabled. This method returns a ModuleDefinition object that provides information about the server-side module service code and about the client-side code.

    The following code is a skeleton example of a module service and provider:

    namespace Microsoft.DeveloperStory.IIS
        public sealed class AModuleService : ModuleService
            public void SomeMethod()
            public void AnotherMethod()
        public sealed class AModuleProvider : ModuleProvider
            public override Type ServiceType
                get { return typeof(AModuleService); }
            public override ModuleDefinition GetModuleDefinition(IManagementContext context)
                if (context.User.Identity.IsAuthenticated != true)
                    // Do not enable the module.
                    return null;
                    // Enable the module.
                    return new ModuleDefinition(this.Name, 
            public override bool SupportsScope(ManagementScope scope)
                return true;
  2. Define the extension module client UI by implementing a class that derives from Module. In this class, implement the Initialize method to register the features with the IControlPanel service to provide the tool with the UI to populate the tool.

    The following code example demonstrates this implementation:

    namespace Microsoft.DeveloperStory.IIS {
        public sealed class ANewModule : Module 
            public override void Initialize(IServiceProvider 
                serviceProvider, ModuleInfo moduleInfo)
                base.Initialize(serviceProvider, moduleInfo);
                // Retrieve the IControlPanel service, and register the
                // associated pages to be shown in the management tool.
            // Optionally provide a module-scoped task list, etc.
  3. Create the service proxy which is used by components on the client-side to invoke methods on the server-side. The proxy methods correspond to the methods on AModuleService that are marked with ModuleServiceMethodAttribute.

    namespace Microsoft.DeveloperStory.IIS
        public sealed class AModuleServiceProxy : ModuleServiceProxy
            public void SomeMethod()
            public void AnotherMethod()
  4. Deploy the assemblies containing the module service and provider classes to the global assembly cache (GAC) on the server. Deploy the assembly containing the client UI to the GAC on the server (so it can be used in local connections, and streamed to the client as needed for remote connections).

  5. Register the module provider in the administration configuration file, administration.config:

        <add name="ANewModule" type="Microsoft.DeveloperStory.IIS.AModuleProvider, 
          Microsoft.DeveloperStory.IIS, Version=, Culture=neutral, PublicKeyToken=" />
      <location path=".">
          <add name="ANewModule" />

For more information and additional sample code, see How to Get Started Extending Module Properties IIS7 IIS Manager and An End-to-End Extensibility Example for IIS7 Developers.

Community Additions