[MDT] HOWTO:在 MDT 中集成 DaRT
HOWTO:在 MDT 中集成 DaRT
DaRT 即 Diagnostics and Recovery Toolset，是 MDOP（Microsoft Desktop Optimization Pack）的核心功能组件之一。是微软针对 Windows 系统设计的一种高级检测和修复工具，其功能非常强大！富含了多个实用的功能，软件界面可以参考下图。
对于 ITPro 来说 DaRT 是一款非常实用的工具，过去我们需要单独刻录一张光盘来使用，而现在 DaRT 已经能够被集成到 MDT 中，这样我们将能够非常方便地通过网络来启动 DaRT！正如我们所看到的下图的场景一样，那么我们该如何将 DaRT 集成到 MDT 中呢？！其实方法很简单……
首先，您的 MDT 必须是 2012 版本（含 Beta，因为这是 MDT 2012 的一个新特性！），还要有一份 MDOP 的授权（如果 gOxiA 记得没错，Software Assurance 类型的 Windows Client 授权可免费获得 MDOP），也只有这样才能获得 DaRT 组件包。然后将 DaRT 的架构版本拷贝至 Deployment Share 的对应目录下，并在 MDT 中配置一下即可。具体细节可以参考下面的步骤：
- 拷贝不同架构（x86 or x64）的 Tools.cab 文件到 Deployment Share（即我们的部署点目录） 中 Tool 目录下对应的子目录中；
- 打开 Deployment Workbench；
- 在 MDT 控制器中展开“Deployment Shares”找到当前的部署点，并将其选中；
- 鼠标右键单击并点击“属性”；
- 在“Windows PE”选项卡下找到“Features”子选项卡；
- 在“Feature Packs”下复选“Microsoft Diagnostics and Recovery Toolkit (DaRT)”
上面操作完成后，确认退出。之后更新部署点（Update Deployment Share）会重新生成 MDT 的启用映像文件，最后将其重新添加到 WDS 的启动映像中，大功告成！找一台客户机通过 PXE 引导启动 MDT 就会看到在 Welcome 界面中的“Run DaRT Tools”。
[TMG] 解决 TMG 服务器日志报 ADWS ID1202 错误的问题
解决 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] 解决因 TMG 配置数据不完整引发的 MMC 操作故障
解决因 TMG 配置数据不完整引发的 MMC 操作故障
最近遇到一个 TMG 故障，在使用 TMG 控制器进行配置操作时没有问题，但是保存时提示错误，仔细查看发现在规则列表中竟然有两个规则只有名称而没有其他配置信息，当去操作或查看时会报下面的错误截图，导致无法对 TMG 进行操作和修改。
回忆一下之前的操作，极有可能是因为两个管理员同时配置 TMG 在保存时，配置数据未能同步，从而引发了此故障问题。之后给微软开了 Case，提出了两个解决办法：
- 使用 TMG 光盘对安装进行修复。（PS：感觉这个解决办法风险太大，首先要暂停网络访问，而且可能会导致之前的规则丢失。）
- 直接操作 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
