gOxiA=苏繁=SuFan Blog

Office Deployment Tool 相关配置参考信息

        通过 Office Deployment Tool（ODT）安装的 Office 有一个显著优势就是日后更新非常便捷，只需在 Office 账户下通过更新选项即可将当前 Office 升级到最新版本，而且利用 ODT 还可以下载安装最新的 Build。gOxiA 曾分享过两篇有关的文章“HOWTO: 从本地位置部署 Office365 ProPlus”、“Office 2016 Deployment Tool 现已发布”。

        使用 ODT 不仅可以针对企业级部署和安装 Office 365 ProPlus 这些主要商用版本，还能获取到更多的 SKU 以及更多的语言版本。而要获得更多的资源就依赖特定的配置信息，例如要获取 32 或 64 位版本，我们需要使用“OfficeClientEdition”，值 = 32 或者 64 即可。

        对于要获得更多 SKU，即 Edition 发行版本，则需要指定“Product ID”，下面列出了各 Edition 所对应的值。

        而下表则是语言版本，即“Language ID”所对应的值。

解决 Office Outlook 邮件不显示图片内容

        首先声明这是一个不是“问题”的“问题”，之所以这么讲是因为在 Outlook 中阅览邮件内容时发现图片内容无法显示，只显示一个图片框。而这一问题的原因其实是设计使然，即它是一个功能，而并非真正的故障，具体的表现如下图所示。

        在对这个问题进行排错的时候可谓艰辛，翻遍了整个 Outlook 设置，终于在邮件撰写窗体的编辑器高级选项下找到了对应的设置“显示图片框”，在选项旁边的注释中明确了该功能所产生的“影响”，但是一般用户还真不会注意到。要不是针对这一问题为用户排错，连 gOxiA 自己也未必真实了解。

        自 Office 2007 开始到 Office 2016 版，这个功能一直存在！！！当勾选“显示图片框”后，邮件内容中的图片会用空白框来代替，从而提高滚动性能。因为它不是一个全局设置，所以在 Outlook 选项中是找不到的，必须新建一封邮件，在邮件撰写窗体下进入选项，在编辑器高级选项中才能找到这个设置。（PS：隐藏至深，所以也会被一些国内的软件商利用，目前常见的Windows系统故障或应用软件故障通常都是安装国产第三方类似应用后被恶意篡改设置而引发的故障，致使用户放弃正在使用的应用程序……）

        对于“显示图片框”这个选项所对应的配置文件位置或注册表位置，倒是一直没有时间用抓包工具深入研究，因为在实际排错时发现该选项在去除勾选后，关闭再打开 Outlook 会重新生效，而最快的解决办法是重建了Windows 用户配置文件，如果您对这一问题有深入研究，还望不吝赐教！

HOWTO: 解决 Windows DISM error ID3 0x80070003 故障

        DISM error ID3 的故障描述，自定义的 Windows 7 标准化系统映像测试正常，封装后在测试环境中部署时发现在 offline mode 下使用 DISM 对系统进行管理时操作失败，如下图所示 DISM 未能找到有效的 Windows 目录，但是当前系统路径确实是有效的，本以为是封装前的系统出现了异常，也反复进行了原始映像的测试，并对当前系统进行了检查并未发现有什么可疑的地方，无奈只能重点排查 DISM 日志！

        在对 dism.log 文件进行了分析后，发现了详细的报错信息，DISM 在对脱机映像执行操作时发生了错误，“DISM OS Provider: PID=1420 Failed to mount the remote registry...(hr:0x80070003)”！复查系统映像创建中的配置修改以及后续部署时无人应答文件的设置，可算找到了线索在应答文件中对用户配置文件进行了重定向，该设置会将 Users 目录移动到其他分区，这就导致“All Users” 和“Default”目录也被移动，而 Default 目录包含默认的注册表数据文件（NTUSER.DAT），当 DISM 对脱机映像管理时会去 Mount 这个注册表数据文件，所以最终导致操作失败。

        而要解决这个问题的办法还是相当简单的，就是在系统所在分区创建一个相同的目录结构（C:\Users\Default\）, 并将 Windows 安装源（Install.wim）中的 NTUSER.DAT 文件拷贝过去即可。在微软官方的知识库（KB2293874）中确认了这是一个已知的问题。

        随后 gOxiA 在 Windows 10 上也重现了这个故障问题，dism.log 中记录的错误提示稍有区别，但意思完全相同，所以解决方法一致。为什么时隔7年这个问题仍旧没有解决，恐怕也只有产品组的人员知道！不过也完全可以理解，在企业环境中要重定向用户配置文件目录通常会使用组策略进行设置，此法不会移动系统级的目录；而直接通过应答文件的做法恐怕也是极为罕见的场景需求。