[SBS]解决在 SBS2011 上因压缩模块导致的 HTTP 500.19 故障问题
解决在 SBS2011 上因压缩模块导致的 HTTP 500.19 故障问题
前一篇与大家分享了因开启 32BitApponWin64 后出现的 HTTP 503 故障问题(http://goxia.maytide.net/read.php/1678.htm),而本篇还是与 IIS 和 ASP 有关。接二连三出现问题也并不是 gOxiA 所希望看到的结果,但是之前在调试那个 ASP 程序时确实很不顺利,在 503 故障解决之后紧接着就是 500.19 故障。
大家知道 500.19 是常见故障,导致该问题的出现原因有很多,如果仅是单纯看错误摘要“无法访问请求的页面,因为该页的相关配置数据无效”,是很难确定故障原因的。
所以我们需要将重点放在详细错误信息中,以本案为例,参考下图可看到在详细错误信息中提示“模块 DynamicCompressionModule”出现错误,错误代码为“0x8007007e”。
检查了 Windows Server 2012 Essentials 环境,发现该 ASP 程序所在网站也启用了压缩模块,但访问是正常的。此外在 iis.net 上找到一篇相关的帖子 http://forums.iis.net/t/1149768.aspx/1/10,貌似与 SBS2011 上集成的服务应用有关,尤其是 WSUS,涉及文件“suscomp.dll”,suscomp.dll 是 WSUS 的专用压缩模块。
起初,gOxiA 参考帖子直接将加载的 suscomp.dll 语句注释掉以禁用加载,之后测试 ASP 程序确实就正常了,但这样以来就要牺牲掉 WSUS 的压缩模块。suscomp.dll 属于全局类型的模块,它根据压缩的类型(动态或静态)由 IIS 的 compdyn.dll 和 compstat.dll 进行调用,所以在 IIS 管理器的站点模块管理中也找不到对应的配置信息,所以单独对站点禁用该模块是不可能的。
此外想单纯通过禁用站点的压缩功能也是不行的,因为相关的模块还是被加载了,只要加载就会导致故障的出现。
所以要彻底解决这一故障的唯一办法就是将对应站点中的动态和静态压缩模块全部给删除掉,不予以加载。要直接为单独某个站点删除模块,是不行的!会提示错误“锁定冲突”……
为此,要修改 IIS 服务设置,即在 IIS 管理器里选中当前服务器,通过内容窗体中的“模块”进入其设置,找到对应的模块(如:DynamicCompressionModule),在任务窗体中点击“解除锁定”,之后才能在对应站点中对模块进行删除。
因为涉及到的是全局的 suscomp.dll 模块,所以为了保证 ASP 程序正常访问,除了要删除 动态压缩模块以外,同时还要删除静态压缩模块(StaticCompressionModule)。现在 ASP 程序便可正常访问了,而且也不会影响到 WSUS 服务。(PS:不能再拖了,要尽快完成 SBS2011Std 到 WS2012Ess 的升迁工作!!!)
[SBS]解决因开启 32BitApponWin64 后出现的 HTTP 503 故障问题
解决因开启 32BitApponWin64 后出现的 HTTP 503 故障问题
自从离开 Hosting 行业,好久没有做过 IIS 方面的排错,今天算是遇到了一个,感觉会很常见,所以记录下来以备后用。用户购买了一套 ASP+Access 的小程序(PS:别问为什么还要买这么老旧的架构程序!),配置到用户的 Windows Server 2012 Essentials 环境中运行正常,操作过程并无什么特别,只是为其应用池开启 32位程序支持即可,整个过程非常顺利。
反而在之后配置到 gOxiA 的 Windows Small Business Server 2011 Standard 环境中后一直无法正常运行,IE 访问时提示“Service Unavailable”,经典的 HTTP 503 故障。起初检查 IIS 配置没有发现异常,但是看到对应的应用池会被停掉。于是打开事件查看器查阅日志,发现了很多来源为“IIS-W3SVC-WP”的错误,其内容大致如下:
“由于配置问题,无法加载模块 DLL “C:Program FilesMicrosoftExchange ServerV14ClientAccessOwaauthexppw.dll”。当前配置仅支持加载为 x86 处理器架构构建的映像。……”此外,除了 exppw.dll 文件外还有 kerbauth.dll 也出现错误。
综上分析,应用程序池的 32位应用支持是正常打开了,但是却无法加载 64位的 DLL 文件。而关闭“enable32BitAppOnWin64”后应用程序池恢复正常,但无法访问 ASP 程序。那么原因应该是出在应用程序池和加载模块的问题上。“exppw.dll”和“kerbauth.dll”文件都属于服务器上的 Exchange Server 2010 所有,这两个文件本身肯定是没有问题的。
看来还是要锁定到应用程序池方面,应用程序池本身是64位的,只是开启了32位应用支持,所以应用程序池在设置后是正常运行状态。当触发访问请求时,该应用程序池会启动一个新的32位模式的进程,来接受 ASP 类型的访问请求,此时就会导致 32位应用程序池进程(w3wp.exe)与加载的 64位 DLL 出现系统策略上的冲突,被系统强行终止,最终出现前面所述的故障。
要解决这个故障貌似挺难的,难不成跑了64位应用(Exchange Server 2010)的服务器就不能跑 32位 的 ASP 程序了?!看来只能网上找找是否有相关的资料,这还真的找到了!参考资料:http://blogs.msdn.com/b/rakkimk/archive/2007/11/03/iis7-running-32-bit-and-64-bit-asp-net-versions-at-the-same-time-on-different-worker-processes.aspx
文中末尾提到可以修改“applicationHost.config”文件,为加载的 DLL 指定对应架构模式的 ISAPI Filter 来运行。即,在每个 DLL 加载配置行尾附加“preCondition”参数,如果该 DLL 是 32位那值为“bitness32”,而 64位的则是“bitness64”。修改后的结果可以参考下图:
针对本例,我们需要修改的有两个:“exppw.dll”和“kerbauth.dll”。最后测试一下结果,网站已经能够正常访问,至此故障消失问题得到了解决!同样,有遇到类似故障的都可参考此法解决。
[IIS] HOWTO:使用 Web Deploy 便捷发布网站程序
HOWTO:使用 Web Deploy 便捷发布网站程序
gOxiA 最近找了一个 .NET 的开源网站程序,改吧改吧当作企业网站来用,该网站程序需要 SQL Server,由于改动比较简单所以没打算使用复杂的开发环境,WebMatrix 就成了不二之选!借助 Web Deploy 技术,在发布网站的同时还能将数据库一并发布,简单快捷,并且无需在 Web Server 上安装 FTP。
Web Deploy 是 IIS 的一个插件,最新版本是 v3.0 Beta,本篇日志将以 Web Deploy 2.0 为例与大家分享,Web Deploy 可以从 Microsoft Download Center 获得,下载地址如下:
Web deploy 2.0 简体中文版:http://www.microsoft.com/downloads/zh-cn/details.aspx?familyid=cfa66d50-90ce-49cba-b021-fefbd7a302ab
Web Deploy 的安全访问机制和访问接口都依赖于 IIS 的“管理服务”组件,所以要使用 Web Deploy 必须先安装 IIS 的“管理服务”。为此,首先打开“服务器管理器”添加角色服务,整个安装过程非常简单不再复述,可参考下图:
在“管理服务”安装完毕后即可执行 Microsoft Web Deploy 2.0 的安装程序,过程依旧非常简单一路“下一步”即可,过程可参考下图:
Web Deploy 安装完毕后,便可进行下一步的配置过程。首先请确认“管理服务”是否已经在运行,如下图所示:
之后进入“IIS 管理器用户”添加一个账号,这个账号是基于 IIS 的,并非 Windows 账号,所以在安全方面会更强一些。
下来,就可以为需要使用 Web Deploy 的站点添加管理账号了。选中一个站点,进入“IIS 管理器权限”,在操作窗体中点击“允许用户…”,之后从 IIS 管理器中添加用户即可。
最后,便可在 WebMatrix 中的发布设置中选择“Web Deploy”,其中“服务器”填写 Web Server 的 IP 地址,“用户名”、“密码”即是之前在“IIS 管理器用户”添加的信息,而“网站名称”需要填写的是与 IIS 里站点对应的名称,如果当前 WebMatrix 站点配置有数据库,那么还可以在发布设置下通过 Web Deploy 配置数据库信息,使发布网站的同时也将数据库传递给 Web Server。
上述步骤完成后点击“验证连接”,因为当前 Web Server 使用了自签名证书,所以会有如下图的警告提示,我们只需复选“为 WebMatrix 的将来会话保存此证书”,并点击“接受证书”便可继续连接。
Web Deploy 的功能非常强大,除了 WebMatrix,还能利用微软的 Visual Studio 实现更为便捷、高效、智能的网站发布。由于 gOxiA 不是专业的开发人员,所以 Web Deploy 更多的经验恐怕无法与大家分享。
最后,关于 Web Deploy 使用“IIS 管理器用户”时的目录安全权限方面的经验再与大家分享一下,根据实际的测试当使用“IIS 管理器用户”进行 Web Deploy 发布时,目录权限要添加“Local Service”账号有修改权限。此外,如果你希望使用 WebMatrix 来检查网站兼容性,那么还需要为 Web Server 上的网站所在目录添加“Service”账号有读取权限。