[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”。最后测试一下结果，网站已经能够正常访问，至此故障消失问题得到了解决！同样，有遇到类似故障的都可参考此法解决。
[Office]在域环境中部署 Office 2013 管理模板
在域环境中部署 Office 2013 管理模板
最近在进行一个 Office 的测试，涉及 Office 的管理模板，之前的版本如 Office 2010，我们可以通过组策略编辑器（GPMC）直接导入管理模板，操作很方便。如下图所示：
但是如果要部署 Office 2013 的管理模板，貌似就不能再用上面的方法了，我们会发现在 Office 2013 ADM 中根本没有可导入的策略模板类型的文件。
搜索了 TechNet，找到了相关的文档“Office 2013 组策略概述”，根据其说明了解到，要部署管理模板需要手工创建指定的目录并拷贝相关的策略模板文件。
- 管理模板文件存储在本地计算机上，位置如下：
文件类型
文件夹
.admx %systemroot%＼PolicyDefinitions .adml %systemroot%＼PolicyDefinitions＼<zh-cn> - 域环境中央存储，位置如下：
| 文件类型 | 文件夹 |
| .admx | %systemroot%＼sysvol＼domainpolicies＼PolicyDefinitions |
| .adml | %systemroot%＼sysvol＼domainpolicies＼PolicyDefinitions＼<zh-cn> |
因为是在域环境中部署，所以参考后者。定位到对应的目录后创建“PolicyDefinitions”子目录，之后将下载到的 Office 2013 ADM 解压缩，在 ADMX 目录中选取我们要使用的模板文件，因为是简体中文环境所以仅拷贝 zh-cn 目录和所有的 .admx 文件即可。
下图是部署到中央存储后的截图，请参考。
现在打开 GPMC 创建一个新的 GPO 以开始配置 Office 2013，如下图所示。
但是大家也注意到了，在管理模板视图下只显示出 Office 2013 的策略，而默认的管理策略都消失了。
就此问题也专门搜索了网上的资料，可惜没什么可用信息，之后向微软开了支持事件，经过几番讨论分析的结果是，当 DC 上未使用集中策略存储目录时，则组策略编辑器就会从“C:＼Windows＼PolicyDefinitions”读取。否则就会首先从集中策略存储目录读取。
既然有了分析结果，问题也就迎刃而解了，我们只需要将本地“PolicyDefinitions”目录下的文件都拷贝到集中策略存储目录下即可。
