Surface Pro 4 批量部署系列 - Windows 10 激活
Surface Pro 4 批量部署系列 – Windows 10 激活
回顾上一篇文章“Surface Pro 4 批量部署系列 - 驱动程序安装 ”我们掌握了 Surface Pro 4 批量部署时驱动程序的处理，并且可以参考“HOWTO: 在执行 Sysprep generalize 后保留预部署的硬件驱动 ”，在执行 Sysprep 时保留驱动，以加速部署速度，接下来我们就可以应用这个映像进行测试。
Surface Pro 4 随机预装 Windows 10 Pro 版，并支持自动激活，本以为联网激活的时候会自动提取主板固件中的密钥，但实际测试并没有那么智能。所以要实现免序列号自动激活 Surface 必须先解包原厂系统执行 OOBE 联网激活系统一次，否则就需要单独输入有效密钥来激活。
Windows 10 的激活技术是进行了改进，OEM 版每个主板都内置一个唯一的密钥，而不管是OEM还是零售版，这个密钥在首次激活后会绑定当前设备 GUID 或 LiveID，所以当以后再执行干净安装时就能在联网的时候自动识别，并激活系统。改进的激活技术确实很方便，但对于批量部署的用户来说，将是“噩梦”！单单解包原厂系统就要耗费掉不少时间，更别说后续还要部署定制版系统。
gOxiA 就经历了这个过程，之前测试环境是一台已经激活的 Surface Pro 4，封装镜像测试激活正常后，开始分发！后续便遇到了新拆封从未激活的Surface设备，起初的报错信息是 0x2a 0x803F7001，中文提示 0x803F7001 在运行 Microsoft Windows 非核心版本的计算机上，按照提示执行 slui 查看具体的错误信息。
从错误信息上看并没有什么价值，难道是序列号对应的 SKU 不对，换了几个密钥均没有解决，随后联系微软技术支持，使用 WCF 的 Error 查看工具分析了代码得知是网络问题，果然在调整 HOSTS 后测试环境下的Surface能够激活了，但发现在分发给新设备后还是会报错误，导致无法激活。
几经折腾，最后才意识到是因为使用通用密钥是无法激活新拆封的设备的。期间也尝试提取原厂系统的文件，发现密钥部分是加密的，而且也证明激活程序不会自动提取主板固件中的 OEM 密钥，那么原厂系统的预置的密钥应该是一个真正意义上的黄金密钥，可惜被加密了，也只能放弃！除了恢复原厂系统，唯一的希望就是从主板固件提取密钥，还好微软为我们预留了 WMI 接口，我们只需要利用 WMI 把 OA3xOriginalProductKey 的值提取出来即可，拿到了唯一的密钥就可以使用 slmgr 来重新激活 Surface Pro 。
注：OA3xOriginalProductKey 位于 SoftwareLicensingService 下。
Surface Pro 4 批量部署系列 - 驱动程序安装
Surface Pro 4 批量部署系列 - 驱动程序安装
Surface Pro 4 在企业环境中批量部署时需要考虑的问题和细节还是非常多的，目前 Surface Pro 4 出厂预装的系统为 Windows 10 Pro x64 1511 版本，在交付最终用户使用前通常需要对企业设备的系统进行定制，例如升级到最新版本，安装最新的系统补丁包、更新设备固件、常用工具、商用程序以及安全软件。由于 Windows 10 的周年更新（1607）已经发布，如果基于出厂预装系统进行定制，还需要进行夸版本的升级比较麻烦，为此会直接基于 1607 定制新的黄金镜像。在定制镜像时需要考虑的一个主要问题就是驱动。
在进行标准化定制中，处理驱动程序的安装，通常会通过 MDT 加载驱动，并在安装过程中动态注入到系统中。但 gOxiA 在实践中发现默认的任务序列只会注入发现的设备驱动，这样就导致系统安装后一些设备并未完整的载入驱动，如下图所示：
要解决这一问题，我们需要修改任务序列中的“Inject Drivers”部分，选择“Install all drivers from the selection profile”，这样在部署过程中就会将 Surface Pro 4 的所有设备驱动和固件强行注入到系统中，以完成后续的安装。
注意：如果当前部署解决方案框架包含多种设备，可以先创建一个 selection profile，包含 Surface Pro 4 的驱动，这样可避免将其他设备驱动也一同注入系统的问题。此外，在日后正式部署时 IT 人员应当确保 Surface Pro 4 在安装系统时的电量不低于 30%，因为 Surface Pro 4 的驱动包包含最新的固件程序，当电量低于 30% 时，系统策略会拦截固件的更新。
HOWTO: 解决 Surface Deployment Accelerator 的 Boot Drive was not found 错误
HOWTO: 解决 Surface Deployment Accelerator 的 Boot Drive was not found 错误
在 Surface Deployment Accelerator 的道路上处处是坑，之前才出了因标点符号编码错误引发的脚本执行错误，这还没走几部就遇到了“FAILURE (5615): False: Boot Drive was not found, required?” 错误！
SDA 的初始化其实就是自动创建一个适用于 Surface 设备部署的 MDT 部署点，所以在任务序列中会自动添加两个基本任务：1 – Deploy Microsoft Surface 和 2 – Create Windows Reference Image。gOxiA 在测试第一个任务时并未发现异常，知道开始测试第二个任务序列才遭遇到上面的错误，提示找不到引导驱动器。这个问题还是比较容易排错的，在测试客户端上使用 diskpart 检查磁盘，发现任务默认创建的分区有异常，随后在 MDT 中检查该任务序列，发现 Preinstall – New Computer only 组下只有一个分区格式化任务序列，真搞不懂这次是也是因为编码问题所致吗？怎么很明显的感觉是人为挖坑呢？！
不管是人为还是什么原因，免费的解决方案还能过多要求什么呢？！自己动手改改就好，修正并创建两个分区格式化任务，一个针对 MBR，另一个则针对 UEFI。两个任务通过选项添加变量条件进行识别并执行。
如上图所示，在 MBR 类型的任务选项中添加一条 Task Sequence Variable Condition，其中 Variable 为 IsUEFI，Condition 为 not equals，Value 为 True； UEFI 类型的条件则相反。最后修正分区格式化任务的卷设置，通常 MBR 类型是 499MB 为引导分区（FAT32），99%系统分区（NTFS），剩余 1%（实际创建时填写 100%） 为恢复分区（NTFS）；而 UEFI 类型是 499MB 为引导分区，128MB 的 MSR 分区，99% 的系统分区和 1% 的恢复分区。
