IIS7. Management API

  • Article

Asking about what will be available in an unreleased product like IIS 7.0 is pretty risky. Even at this point, there is still a lot of flexibility in terms of features "not making it", so I am making no promises. I can only say what is valid at this point in time and you will have to apply the necessary pinch of salt...

Question:

Do you know what APIs will be available for management/provisioning of IIS 7.0? I currently use a mixture of WMI, ADSI, and ABO to manage/provision websites on IIS 6.0.

Also, do you know if the IIS 7.0 "metabase" (or whatever it ends up being called) is shareable across multiple machines? I currently replicate the metabase across all the IIS nodes in my cluster. Allowing them to share a single instance is something I've been looking forward to for years.

Thanks,

Answer:

The current plan is that all existing APIs will still function on IIS 7.0 as-is for compatibility reasons. However, these APIs will only be able to configure settings up through IIS 6.0 - they will not be able to configure nor take advantage of any feature set introduced with IIS 7.0. In other words, it is totally for the compatibility story. If you want to natively configure all IIS7 features, you will have to use the brand new management APIs.

Sorry, it would have been a lot of work to make the older APIs forward-compatible with the new IIS 7.0 configuration store, introduce a lot of logical discontinuities and bugs in the effort for unplanned "forward compatibility" (the administration models are fundamentally different and some domain mappings are not clean), and the customer benefit from hiding such details is not clear.

I know I know, customers always say that "if you make me change anything I already have, it cannot be beneficial" because "if it ain't broke don't fix it", but then again, I question why you migrate to IIS 7.0 from the existing platform "if it ain't broke". If you want the new features, then you need to be prepared to make changes... and IIS 7.0 introduces plenty of fundamental changes that you should reconsider taking advantage of.

For example, in my mind, the big changes from IIS5 to IIS6 centered around security, performance, and reliability, and the big technological shift was the IIS6 Worker Process Isolation Mode. In contrast, the big changes from IIS6 to IIS7 are quite a bit more:

  1. The core server introduces a new extensibility API on top of which 40+ modules are written to emulate IIS6 behavior, including the legacy ISAPI Extension, ISAPI Filter, and CGI APIs.
  2. The configuration introduces a new extensibility API and shifts from centralized and machine-specific configuration file to be distributed, delegatable, and machine-independent (well, assuming you put in values that are machine-independent).
  3. The UI shifts from classic MMC Snapin to an HTTP client/server based WebApplication.
  4. The administration APIs update accordingly to match the new distributed configuration.
  5. The IIS6 Process Model becomes a more generic activation model to integrate with Windows Communication Foundation (I think that is what Indigo is publicly named).

For any given product release, any one of the above is a big shift on its own. Well, we are doing all of them simultaneously in IIS 7.0. Yeah, get ready to see some major changes, and I hope you like them.

In other words, if you are just expecting the same-old IIS behaviors and maybe some performance boost - I suggest you stick with IIS 6.0. To truly take advantage of IIS 7.0, there will be many changes, and our goal is to make as many of them as possible to be positive changes.

//David