以前のIISではこの辺はよく現場で見ていたので早速。
こういう構成を採用するのはお奨めですし、組織体としてはそれぞれ別のチームが担当することがよくあることでしょうから、同じことを考えている方は数多くいらっしゃると思います。いずれMSのIT部門がどこかでセッションをやるとそれを日本語化してよりディープな話をお届けできると思いますが、ここではまずさらっと。。。
意外と順方向でステップアップしていく通常の流れよりも逆流することの方が現場では結構あるんじゃないでしょうか。まあ本当にプロセスをきっちり固めているお客様はもちろんこれに当てはまりません。
逆流とはもちろん本番運用環境の構成＋アプリの運用バージョンを他の環境に移植する、あるいは開発環境をある時点で本番に合わせるということを指します。
新しい configuration システムは applicationHost.config がサーバー全体のIIS構成、それぞれのWebサイト階層、アプリケーション階層にある web.config がサイトあるいはアプリケーション固有の構成を持ちます。鋭い方はもうお気づきだと思いますが、継承をするメカニズムである訳ですから 当然 上位（サーバーレベル）の標準化を推し進めないと下位（サイト、アプリ）をコピーをすることによるアプリ配布は必ずしもうまくいきません。
従って、企業で あるいは システム単位で 標準を決めることを推奨します。標準化をIIS6でできている場合にはIIS7のConfigでどうすべきかだけ判断できれば後は委任をして下位で構成の管理を担当する方にマニュアルを配るだけでスムーズに運用できると思います。この際、Fx＋ASP.NET＋IISの組合せでルール化するのがいいでしょう。委任については新機能なので多分新検討事項になることが想定できます。
もう一つ言っておくと、applicationHost.config 以外に administration.config というファイルが同じフォルダにあります。こちらは管理系の情報が詰まっている物になります。例えば新しいIISマネージャを拡張する場合にはここに記述を加えたりします。なので、このファイルに記載されることもルール化する想定で臨むといいでしょう。もしメンバーシップデータベースとの統合を検討するのであれば接続文字列やデータの保持場所など他にも検討することが増えるでしょう。
もしルール化する際にそもそも構成の一覧がほしいなあという場合にはスキーマをご確認いただくことをお奨めします。c:\%windir%\system32\inetsrv\config\schemas にある三つのファイルです。
もう一つ追加補足をしておくと、実はCOM+コンポーネントについてはApplication Centerという製品が展開支援をしてくれていましたが、Longhorn Serverに部分機能統合されることになっています、ロードマップ的には。で、IIS7の開発が一段落したところでこういう展開系のテクノロジーが本格始動するようなことをBill Staples（IIS開発ユニットの責任者）がウェブキャストの中で言っています。実はプロジェクトはもう動いているとのことです。
The .NET SHOW: Robert Hess interviews Bill Staples and Scott Guthrie about IIS7
何かいいUpdate情報があればまた書こうと思います。
