IIS 7.0能够与ASP.NET框架高度集成，并且提供了完整的API，从而可以为平台提供完整的可扩展能力和管理接口。还提供了配置委托和完整的诊断套件，诊断套件可以对需求进行跟踪，还提供了高级日志功能。IIS 7.0将ASP.NET与请求管道进行了集成，这也许是IIS 7.0所做出的最为重大的改变。
IIS 7.0的模块化设计还有利于我们开发定制模块，而且附加功能也更容易实现。从而有利于将内部开发的功能与IIS更好地结合，还有利于将第三方资源与IIS更好地结合，甚至有利于微软公司开发的功能与IIS更好地结合。这是因为：无论何时，在无需修改操作系统核心功能的情况下，这些模块和附加程序都可以作为IIS的插件进行工作，因此微软公司的IIS开发团队可以在微软公司的标准service pack过程之外发布功能模块。

集成的请求管道
IIS 7.0最大的变化之一是它可以与ASP.NET及ASP.NET进程进行紧密集成。IIS 7.0提供了统一的事件管道，该管道将现有的两种独立管道----即IIS管道和ASP.NET管道进行了合并，这两种管道是IIS 6.0以及先前版本的IIS提供的。ASP.NET的HTTP模块原先仅侦听ASP.NET管道的事件，现在可以监听任何请求。为了向后兼容，IIS 7.0还提供了Classic管道模式，Classic管道模式可以模拟IIS 6.0的IIS管道，也可以模拟IIS 6.0的ASP.NET管道。

IIS 7.0提供了一个单独的统一管道。ASP.NET提供的Forms身份验证和角色管理是身份验证和授权过程的组成部分，因此对一个请求仅验证一次。在IIS 7.0中，所有的请求都要经过ASP.NET的Forms身份验证模块进行处理，而不仅仅是那些具有.ASPX扩展名的文件才需要由ASP.NET的Forms身份验证模块进行处理。例如，对 www.domain1.com/images/myimage.gif 的请求首先要传递给ASP.NET的Forms身份验证进程，如果web.config文件中的某种身份验证方式拒绝访问该文件或文件夹，那么缺少权限的用户将无法观察或下载该图像。现在将请求传递给管道并退出，然后再传递给发出请求的浏览器，因此无须再传递给ASP.NET等ISAPI进程。考虑到兼容性问题，尽管ISAPI处理程序退出时需要返回一个退出编码，但是实际上请求并没有在ISAPI中进行处理，如果我们不需要考虑遗留代码的兼容性，我们甚至不需要加载ISAPI处理程序。

在 IIS 7.0管道内部，每个进程都由一个单独的组件进行处理。需要使用这些组件的网站可以单独加载这些组件，如果网站或应用程序不需要在管道中使用这些组件，那么就无须加载这些组件。在应用程序级、网站级和服务器级，这些组件都是可配置的，而且，我们可以在上述任何一个级别中委托组件的配置功能。此外，我们还可以将自定义的组件插入管道，甚至可以将管道中组件的执行顺序重新进行排序。例如，当请求开始执行时，可以触发一个日志跟踪操作，并且当请求结束处理后，将日志跟踪写入一个文件。组件的执行顺序就是各个组件在配置文件中所处的顺序。

可配置性
IIS 7.0的另一个变化是：IIS的配置过程已经集成到ASP.NET应用程序的配置过程中，这个变化是一个相当显著的变化。现在我们无须再使用IIS注册表设置，而原先作为IIS配置库的metabase已经被基于XML的配置文件所取代，这个基于XML的配置文件中同时保存了IIS设置和ASP.NET设置。这样，不仅消除了ASP.NET应用程序和应用服务器之间的界限，同时还提高了IIS的可配置性，简化了网站和应用程序的部署过程。同时，在web farm中的多系统上部署应用程序也更为方便，并且改善了配置的可扩展性。IIS 7.0引入了共享配置的概念，在这个概念中，多个web服务器可以使用同一个物理文件作为各自的配置文件，这样如果我们对web farm的配置进行修改，那么修改的内容可以马上生效。
现在，IIS 7.0使用一个名为applicationHost.config的文件保存设置，此外，针对一个独立的Web网站或Web应用程序，IIS 7.0的配置选项也可以随着ASP.NET的设置一同保存在web.config文件中，当然，IIS 7.0的配置选项保存在该文件的system.webServer一节中。

1.使用applicationHost.config配置文件

IIS 7.0使用文件applicationHost.config为Web 服务器和集成模型保存IIS配置，现在，全局配置保存在%windir%\system32\inetsrv\config 目录下的applicationHost.config文件中，该文件包括两个主要的部分：

（1）system.applicationHost 这部分内容保存了网站、应用程序、虚拟目录和应用程序池的配置信息。

（2）system.webServer 这部分保存了其他设置及全局默认设置。

对URL位置所进行的配置既可以保存在applicationHost.config文件中，也可以保存在web.config中。这样，管理员可以设置服务器上的默认设置，而开发人员可以在必要的情况下重新定义这些设置。这些设置可以由web.config文件在根级和应用程序级进行继承。在对设置进行委托时，这一点非常重要，因为IIS管理员可以允许开发人员在应用程序级以很细的粒度对设置进行控制，同时，IIS管理员还能够在网站级对设置进行控制。

2.可扩展的配置架构

利用新的配置模型，可以很容易对 IIS 7.0配置进行扩展。现在，假定我们需要为 IIS 创建一个新的模块。此时，需要在 applicationHost.config 文件的 一节指出模块对应的 DLL 文件，然后，在 applicationHost.config 文件中或适当的 web.config 文件中声明该模块。为新模块扩展配置架构与在系统的 inetsrv\config\schema 目录中创建架构文件一样简单。通过在 applicationHost.config 文件的配置节中添加一节内容，就可以完成这项工作。

组件化
IIS 7.0的可扩展性不仅表现在配置过程。因为 IIS 7.0对请求处理管道进行了修改，通过使用本机代码和托管代码，核心服务器本身也得到了扩展。这种扩展性来源于 IIS 核心功能的组件化。此时不需要再使用 ISAPI 过滤器来修改请求过程，我们可以将自行开发的组件直接注入到处理管道中。自行开发的组件既可以是我们自己开发的组件，也可以是第三方工具或组件，还可以是微软公司提供的现有核心组件。所以，如果不喜欢 Windows 身份验证过程，那么不仅可以对所有的文件使用 forms 身份验证过程，而且还可以选择忽略所有内置的身份验证过程，而采用我们开发的身份验证过程。这还意味着：如果不需要处理传统的 ASP 文件，那么只要不再加载对应的组件就可以了。在先前的 IIS 版本中，每个组件需要当作一个单独的 DLL 加载到内存中，现在不再需要加载无关的内容，从而减少了 IIS 7.0的开销。