[MDT]HOWTO: 解决 LiteTouch OEM 发生 DISM Error 11 故障
HOWTO: 解决 LiteTouch OEM 发生 DISM Error 11 故障
MDT 的 Lite Touch OEM 任务序列用于在计算机硬盘上预加载操作系统映像。通常由计算机原始设备制造商（OEM）使用，但一些企业也有类似场景的需求。本文 gOxiA 将于大家分享的是解决实施 LiteTouch OEM 过程中，可能发生的 DISM Error 11 故障问题。
按照标准流程创建完毕 LiteTouch OEM，并生成 Media 后，拿到客户端上进行测试，在释放映像的过程中发生故障，导致 LiteTouch OEM 任务序列终止，如下图所示：
在 Details 中能看到故障发生在 WIM 释放阶段，尝试手动执行命令提示“Error 11”，指出“试图加载格式不正确的程序”。在网上搜索了 DISM Error 11 的相关信息，并没有多大的帮助。更换了其他版本的 DISM 执行同样发生此错误，只能再重新领会错误信息。
gOxiA 尝试调用网络共享中的 WIM 执行该命令行，发现并未有问题。说明 MDT 在生成 Media 时出现了异常，但是向导程序并未成功检测到复制发生了错误，最终导致该故障的发生。而 DISM Error 11 给出的错误提示又未能完全表达意思，误导了用户。
对于 MDT 任务序列的执行过程都是相关命令和资源的调用，如果通过错误提示无法分析故障原因，不妨参考日志手动执行命令行，也许真相就会显露出来。
补充：该问题最终查明，存储 LiteTouchOEM 的媒介是 连接在这台虚拟机上使用 SCSI 接口的虚拟磁盘，而这个虚拟磁盘又存储在固态硬盘上，所以导致近 9GB 的数据以每秒近 500MB 的速度瞬间写入，随后由于手工断开 SCSI 磁盘，导致缓存未成功写入。:-P
[推荐] Surface Precision Mouse 微软精准鼠标
Surface Precision Mouse 微软精准鼠标
好久没有写过硬件相关的日志，说来惭愧！微软这款精准鼠标（Surface Precision Mouse）是在今年3月初拿到的，但直到今天才提笔写推荐，不过通过这半年多的使用体验，也足以证此并非软文。
微软精准鼠标的造型说实话非常迷人，除了线条设计超前，质感也是一流，做工更是好的没话说。除了不便于携带外，真的很难挑出它的毛病。造型采用人体工学，把握起来非常舒服，据说采用了一种高级材质，确实不同于普通的塑料或橡胶。
可编程的功能按键满足不同应用场景，中置滑轮支持平滑滚动，触力反馈。内置可充电电池，待机超长从开始时首次充电到现在半年多，没有再次充电，可能是平常没怎么用，因为官方宣称充电一次约可使用3个月。
此外，微软精准鼠标可支持同时与3台电脑匹配，在安装了软件后，可以块设备无缝切换。什么意思呢？！就是如果你用该款鼠标可同时连接三台Windows设备，在移动到屏幕边缘后，可自动切换到另外一台设备上。当然除了Windows平台外，微软精准鼠标也支持 Mac OS 和 Android，让你没有理由去拒绝它。不要把没有蓝牙作为拒绝它的理由，因为微软精准鼠标还支持 USB 连接，是的！它提供了 USB 2.1 接口，除了充电用途外，还可作为与 PC 连接的纽带。
说了这么多是不是已经非常动心，接下来就静静的观赏一番这款鼠标吧。
微软精准鼠标，你值得拥有，特别是如果你正在使用微软 Surface 电脑，那么这款鼠标真的是绝配，不二的选择。不知道大家是否关注到中置滑轮下面的按键，gOxiA 之前一直没有研究出用法，偶然间才发现原来这个按键可使滑轮在硬件阻尼和平滑间进行切换，真是人性化的设计，考虑如此细微，不惜成本。
说到缺点，与 Surface Arc Touch 比起来，确实真的是不适合携带，不过如果你非常注重舒适度和操控性，那么可以忽略此缺点。
最后，gOxiA 想说近年还败了一只 IE3.0 蓝影复刻版，还没开封，就当收藏了。在上图中，那款性感迷人的笔记本，就是 Surface Book 2，下周 gOxiA 一定将 Surface Book 2 的体验也分享出来，也算是对 2018 年度新 Surface 系列发布前的祭礼！
[Tips]解决因超大内存导致的Windows系统安装故障
解决因超大内存导致的Windows系统安装故障
一台 Dell 工作站，硬件配置有 128GB 内存和 512GB 固态硬盘，IT 人员为 512GB 固态硬盘平均划分了两个分区，在安装 Windows 操作系统时发生故障，具体表现为在 Specialize 阶段初始化系统时发生错误，如下图所示：
检查了相关日志文件，发现记录有 “CopyProfileDirectory from C:\Users\Administrator failed (0x80070070)” 错误事件，经分析 0x8007007 为磁盘容量已满导致的故障。
在当前案例场景下检查，512GB 仅划分了两个分区，且只格式化了用于安装系统的分区，而当前硬件设备配置了超大容量的内存（128GB），导致在 Specialize 阶段生成 Hiberfil.sys 文件后，没有可用空间再生成 Pagefile.sys，因为设备存储没有其他有效格式分区，系统无法利用其他分区存储 Pagefile.sys，最终导致 0x80070070 故障。
这个看似简单的问题实际上在解决过程中非常复杂，尤其是在企业 IT 环境中。如果单纯为了解决本次故障，可以将第二个分区格式化，这样在 Specialize 阶段初始化时，如果系统分区容量不够，则会自动在第二分区上创建 Pagefile.sys。但如果企业采用了定制的标准化系统映像，那么问题就会非常复杂。
起初 gOxiA 计划在 Specialize 阶段的 RunSynchronous 中添加一条命令“powercfg /h off”来实现关闭休眠文件（Hiberfil.sys），但测试发现此条命令并不会生效。翻阅了微软官方的文档提示应该在 RunAsyncronous 中执行该命令，于是又进行了尝试，结果发现并未生效，也检查了相关的日志文件，确实在 Specialize 阶段成功执行了命令，但也确实并未生效。而微软官方文档推荐在 AuditMode 阶段执行，也就是说 oobe 也是支持的，但是这些阶段执行“powercfg /h off”并不能解决本案例实质性问题。
为了解决这个问题只能从注册表下手，可以修改注册表，将系统 Power 下的 HibernateEnabled 键值设置为 0 ，即可禁用休眠功能。测试在 Specialize 阶段执行如下命令行。
测试结果是 Specialize 阶段修改了注册表也不会即刻生效，所以最终的结果是直接修改映像（WIM）的注册表键值。通常采取的做法是 Mount WIM，然后在注册表中加载映像中的注册表文件，位于“C:\Windows\System32\config”。
问题虽然是解决了，但是也引发了其他的问题，企业环境中的笔记本该怎么办呢？！这里给出几个方案供选择：
1. 按照不同机型，分配不同的映像。
2. 按照不同机型，应用不同的应答文件。
3. 不同机型使用同一个映像和应答，附加专为企业定制的配置工具，在配置过程中识别机型，并执行相关配置和维护脚本。
