IIS7. Management API

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

Comments

• Anonymous
  October 19, 2005
  in .net 2.0 beta 1 there was msmetabase.dll that looked interesting, but it seems to have disappeared from later builds, was it dropped ?
• Anonymous
  October 19, 2005
  Daren - msmetabase.dll is dropped and will not ship. We looked at creating a managed code API specific to IIS, but we dropped it because it is not necessary to provide yet another managed-code interface to configure IIS.
  
  //David
• Anonymous
  October 19, 2005
  Thanks, David! ;) Can you comment on the second part of the question as well? Specifically, if a single metabase can be shared by multiple servers...
• Anonymous
  October 20, 2005
  Mark - since the new configuration file is not machine-specific (yet), it can be shared. The feature is planned but I have not seen it yet. It may/not make it.
  
  Personally, I am not keen on the "shared configuration" feature because it is not reliable and complicated.
  
  We have tested ISAPI over UNC and the rate of random crashes due to small network latency and occassional inability to demand page-in memory far exceeds that of ISAPI on local FileSystem. A config file will not be less critical, so I deem the comparison reasonable.
  
  A sharable, unsynchronized configuration is also a dirty problem. I would rather give you a machine-independent configuration file that you can easily replicate/edit/cache to your own liking, than to give you some sharable "solution" that may not work for everyone. Believe me, I have seen past designs on this and the eventual complexity would scare you.
  
  With a machine-independent config, you can implement whatever you want. But if we come up with some "solution", you are stuck with the solution or nothing.
  
  So, I would rather that you push for machine-independent configuration instead of sharable configuration. :-)
  
  //David
• Anonymous
  October 20, 2005
  Have you considered the notion of a "pluggable provider" architecture for IIS configuration? That is, give me an interface to implement such that I can store my IIS config anywhere (i.e. SQL, AD, XML, Text, SOAP, etc.).
• Anonymous
  October 21, 2005
  With regards to AD -> metabase, it looks like the Exchange team has already done this to an extent with the AD2MB service. Wouldn't it be possible to ride on top of what they did, then have the IIS management tools plug into AD much like the Exchange MMC does? Provide it as an option perhaps, so you can have stand-alone IIS boxes or boxes integrated into AD.
  
  Also, can we expect an SSL option for the IIS maangement tools? Or will it be clear text? Will we see webservices for the server portion of the client/server management tool so we can plug a different one in on top of it? When I last in Redmond, this wasn't on the docket, but has it been added?
  
  I agree a machine independent configuration would be cool as well.
  
  My 2 cents. ;)
  
  -matt
• Anonymous
  October 21, 2005
  Mark - Provider model for configuration (funny you should ask because I had also floated around the idea of a provider model for FileSystem access by IIS modules [i.e. your entire website can be mapped into a single ZIP file and ASP/ASP.Net/StaticFileHandler will transparently work]) was considered at one point, but we dropped the idea for many, many reasons, some of which include:
  1. Where does configuration describing the list of active/possible config providers live? Server Core needs to do this to bootstrap reading rest of configuration on a per-request basis.
  2. Is config provider participating as an IIS module or a new extensibility point, and if new extensibility point, how does it tie back to the IIS modules API and is the cost reasonable (cost/benefit perspective over lifetime of product)?
  3. For proper functionality (from end-user perspective), the config must support change notification and obviously must cache extensively. If you do not provide it, many things break in subtle manners. How do we let you know this?
  
  I understand that from your perspective, you just want the choice to do something... but realize that every choice has opportunity costs. Plugable provider lost out to other more immediately interesting features like:
  - "per element lockdown"
  - "per element encryption"
  - "config include file"
  
  All to support rich delegation with a UI (itself a pretty big challenge).
  
  Also note - storage location of IIS config is not as important as "machine independent config" because remote/centralized location is useless without machine independence. I challenge whether the underlying problem can be solved in a better/cheaper way.
  
  So in the end, I think the number of real people benefiting from the listed features probably outweigh the architectural curiosity of a config provider model of the special few. :-)
  
  Yeah, I'm listening and open to be convinced either way... Because we can probably still do a very small handful of big, major changes, so make 'em good. :-)
  
  //David
• Anonymous
  October 21, 2005
  Matt - Unfortunately, AD integration is probably never going to happen; it has never been on anyone's radar, and I rarely ever hear it asked. Can you give me some good usage scenarios of what you want with such a feature and illustrate why it is powerful/useful? I just have no clue what products have effectively utilized it and how.
  
  As for AD->MB service, it is probably not interesting because IIS7 considers MB to be legacy. It is not able to touch all IIS7 properties, so we would need to write something additional. At which point, your answer to my previous question is necessary for us to consider the work-item...
  
  The UI plan as I recently heard: the WebService backend works over HTTP and HTTP by-design, and the WebService will not be exposed as a public API for user extension. The UI frontend will have a publicly documented extensibility interface for user extension.
  
  We are encouraging extension of the UI frontend. If you want to replace it, then it is probably easier for you to rewrite your own corresponding backend WebService.
  
  //David