最近遇到一个 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