gOxiA=苏繁=SuFan Blog

卸载 Exchange 角色时提示“有些控件无效 - 请指定要卸载的现有服务器”

        开始前先声明一小下，感觉这真不应该算是一个技术问题，但发现还真有不少朋友遇到过！当我们要卸载 Exchange Server 2010 角色服务时，可能会遭遇如下图的提示：

        “有些控件无效 - 请指定要卸载的现有服务器角色”，其实这并不是什么故障，只是因为我们习惯了卸载时都是要勾选要卸在的组件，而在 Exchange Server 2010 中要卸载组件则需要清除掉勾选。而在操作页面中，向导也提示的非常清楚 - “清除要删除的服务器角色复选框”，只是大部分“习惯”了的朋友会忽略而已！

        此外，Exchange Server 2010 的修改安装操作，与微软其他产品如：Office，还有一点不同：即，卸载和添加组件是分开独立的操作功能。如果选择更改，那么只能添加角色组件，而不能同时进行卸载选择。

        OK，该问题简单说明一下，没什么可深入探讨的！不过到希望微软以后的产品能更加注意一下用户细节方面的体验！

解决 TMG 服务器日志报 ADWS ID1202 错误的问题

        Forefront Threat Management Gateway（TMG）2010 需要 ADAM 支持，因为它将配置信息都存储在 ADAM 中！所以在正式安装前需要执行“运行准备工具”，而这个阶段会根据用户的选择（安装”Forefront TMG 服务和管理”） 安装必须要的组件支持，如“Active Directory 轻型目录服务”即：AD LDS，用于存储 TMG 配置数据。

        但是，在部署完 TMG 之后，我们会在“应用程序和服务日志”下的“Active Directory Web Services”中看到产生了很多的错误日志，如下图所示：

        仔细查看日志，来源“ADWS”，事件ID“1202”，大致内容“现在该计算机正在托管指定的目录实例，但 Active Directory Web 服务无法为其服务。Active Directory Web 服务将定期重试该操作。……”

        搜索了 Microsoft Support 未找到任何线索，考虑到本机未安装有 Web 服务，所以果断在“服务”管理器中将 Active Directory Web Services 服务禁用（sc config adws start= disabled）。重新启动 TMG 错误日志消失，系统和应用程序工作正常，未发现不良影响！至此问题解决！

    解决因 TMG 配置数据不完整引发的 MMC 操作故障

        最近遇到一个 TMG 故障，在使用 TMG 控制器进行配置操作时没有问题，但是保存时提示错误，仔细查看发现在规则列表中竟然有两个规则只有名称而没有其他配置信息，当去操作或查看时会报下面的错误截图，导致无法对 TMG 进行操作和修改。

        回忆一下之前的操作，极有可能是因为两个管理员同时配置 TMG 在保存时，配置数据未能同步，从而引发了此故障问题。之后给微软开了 Case，提出了两个解决办法：

1. 使用 TMG 光盘对安装进行修复。（PS：感觉这个解决办法风险太大，首先要暂停网络访问，而且可能会导致之前的规则丢失。）
2. 直接操作 TMG 配置数据库，从数据库中删除不完整的规则。（PS：我个人认为这是一种可行的办法，但是直接修改 TMG 数据库的风险也很大，而且要找到规则对应的 GUID。）

        最终选择了第二种解决方法，现在要解决两个问题：如何访问到 TMG 配置数据库；如何确认规则所对应的 GUID。前者，微软工程师给了连接到 TMG 配置数据库的方法，可参考 gOxiA 之前些的日志《使用 ADSI 访问 TMG 的配置数据库》。而后者，gOxiA 尝试导出 TMG 的规则，进行查看果然找到了规则对应的 GUID，如下图所示：

        其中“StorageName”便是规则所对应的 GUID，而且知道规则隶属于“PolicyRule”，接下来参考《使用 ADSI 访问 TMG 的配置数据库》去操作 TMG 的配置数据库（ADAM），如下图所示：

        展开 CN=FPC2，CN=Array-Root，CN-Arrays，CN=GUID，CN=ArrayPolicy，CN=PolicyRules。从字面上不难理解这些项的意思，但是其中 FPC2 表示 TMG 的配置数据库，而导出的规则文件中则为 FPC4，gOxiA 个人认为可能是微软为了区分数据等级，将 FPC2 认定为本机配置，FPC4 为备份配置。

        由于 TMG 的 ADAM 无法查询或筛选，要从 PolicyRules 下找到其 GUID 也确实是件难事，gOxiA 用了一个比较笨的办法，就是先导出列表，然后使用带有标注行号的编辑器打开导出的列表文件进行搜索。一旦找到对应的 GUID 便根据位置靠上从上数的原则确定在第几行，然后再到 ADSI 中去定位！

        最终结果当然是令人满意，未使用修复安装便解决了此故障！ 如果有遇到同样问题的朋友，可以借鉴一下，希望会有帮助！此外，建议对 TMG 有兴趣的朋友可以看一下《TMG Storage》这篇文章，有介绍 TMG 的配置存储机制。其中就讲到了 TMG 还会在注册表中缓存一份配置信息，如果要重建注册表中的配置缓存，可以使用下面的办法：

• 首先在 CMD 中执行如下命令行：
  
  reg add HKLM＼SOFTWARE＼Microsoft＼RAT＼Stingray＼Debug＼ISACTRL /v CTRL_MIXER_CACHE_BUILD_NEW_IN_NEXT_UPDATE /t REG_DWORD /d 1 /f
• 然后重启 TMG 服务
• 最后再在 CMD 中执行如下命令行：
  
  reg add HKLM＼SOFTWARE＼Microsoft＼RAT＼Stingray＼Debug＼ISACTRL /v CTRL_MIXER_CACHE_BUILD_NEW_IN_NEXT_UPDATE /t REG_DWORD /d 0 /f

        原文可参考：Rebuilding ISA Configuration Cache