iis元数据库 iis6管理兼容性

IIS 6.0的数据元数据库（Metabase）是个让人又爱又恨的东西。爱它的管理人说它灵活，恨它的兼容人说它反人类——一个XML格式的配置库，却要依赖专门的数据ADSI接口才能读写。到了IIS 7.0，管理微软彻底抛弃了这套体系，兼容改用基于文件的数据XML配置。可问题是管理，大量老企业还在跑着Windows Server 2003，兼容或者从2003迁移上来的数据应用，代码里还硬编码着对IIS 6管理接口的管理调用。

这时候，兼容IIS 6管理兼容性功能就派上用场了。数据它本质上是管理个翻译层，把老代码对ADSI的兼容调用转译成对IIS 7+配置系统的操作。装了这个功能，你就能在IIS 7、8甚至10上继续用旧的语法管理站点。听起来很美，对吧？但实际用起来，坑比想象中多。

我去年帮一个客户迁移他们的内网OA系统，就撞上了这堵墙。他们的运维脚本用VBScript调用IIS 6的ADSI接口创建虚拟目录，代码长这样：GetObject("IIS://LocalHost/W3SVC/1/ROOT/App")。在装有IIS 6兼容组件的Windows Server 2012上，这脚本居然能跑通。但你要是以为它真能无缝衔接，那就天真了——脚本能创建目录，却无法设置某些新版本才有的属性，比如应用程序池的自动启动配置。老接口只认老属性，新参数传进去直接被忽略，连个警告都不给。

另一个实际问题出现在备份和恢复上。IIS 6的元数据库备份用的是iisback.vbs，它会把整个配置打包成一个二进制文件。但在IIS 7+环境下，即使启用了兼容性，这个备份脚本也只会备份一部分配置——具体说，它备份的是兼容层映射过来的那部分，而新版本独有的站点绑定、SSL设置、URL重写规则等，全都不在备份范围内。有人以为备份了，其实只备份了个壳。我见过有运维在迁移后拿旧备份去恢复，结果站点全回来了，但所有HTTPS绑定全丢，网站直接变HTTP明文。

性能上也有微妙差异。老接口调用每次都要经过一次ADSI到新配置系统的转换，这个转换过程不是零开销的。在高频操作场景下（比如监控程序每隔几秒就轮询一次站点状态），CPU占用会比原生IIS 7+接口高出一截。我实测过，同样的轮询脚本，在纯IIS 6上CPU占用约2%，在装了兼容模式的IIS 10上飙到7%。如果你有大量自动化脚本在跑，这个差距不能忽视。

还有一个没人提但特别烦人的点：错误信息。老接口报错时，返回的错误码跟新系统完全对不上。比如你用ADSI尝试修改一个不存在的站点，IIS 6时代会报"0x80005006"（找不到对象），而在兼容模式下，你可能会收到"0x80070003"（路径不存在）。这俩虽然都是错误，但对排查问题的人来说完全是两种语言。你按老经验去查错误码，结果文档里根本找不到对应条目，白折腾半小时。

说了这么多坑，难道这功能就一无是处？也不是。如果你是纯粹为了兼容老管理脚本，而且那些脚本只涉及基础操作——启停站点、创建应用池、修改绑定——那它工作得相当稳定。关键是要认清边界：它是个兼容层，不是升级工具。别指望它能让你用老接口管理新特性，更别拿它当备份方案。微软自己都明说，这功能只用于迁移过渡期，最终你还是得把脚本改写成新的PowerShell命令或C# API。与其等着被兼容层卡住，不如尽早规划脚本的现代化改造。毕竟，翻译官再厉害，也不如直接说同一种语言来得痛快。

很赞哦!（441）