[MDT]HOWTO: 解决 LiteTouch OEM 发生 0xC000014C 引导故障
HOWTO: 解决 LiteTouch OEM 发生 0xC000014C 引导故障
通过 LiteTouch OEM 默认任务序列制作好 Media，拿到客户端实施，LiteTouch OEM Media 引导正常，也执行了 LiteTouch OEM 任务序列，正常结束并关机。再次开机后，引导过程中发生 0xC000014C 故障，具体错误可参考下图。
该问题通常发生在 UEFI 引导类型的机器上，这是因为 LiteTouch OEM 默认的任务序列中使用的是基于 MBR 类型的分区方案，只有一个 NTFS 格式的分区卷，所以到客户端引导时就会发生故障。
解决办法很简单，在现有“Format and Partition Disk”任务上将其改名为“Format and Partition Disk (BIOS)”，然后根据需要重新划分磁盘分区，再在“Options”选项下添加变量：“IsUEFI not equals True”。
同理再新添加一个磁盘任务序列，命名为“Format and Partition Disk (UEFI)”，定制好分区后，也添加一个变量“IsUEFI equals True”。
最后重新生成 Media，即可解决 0xC000014C 故障问题，且同时支持 BIOS 和 UEFI 类型的计算机。
[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
[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. 不同机型使用同一个映像和应答，附加专为企业定制的配置工具，在配置过程中识别机型，并执行相关配置和维护脚本。
