Windows 10 创作者更新支持无损 MBR to GPT 转换
Windows 10 创作者更新支持无损 MBR to GPT 转换
Windows 10 Creators Update （创作者更新 - v1703 Build15063）即将在 4月11日面向消费用户推送，MSDN 订阅以及 Insider Preview 则会提前一周拿到 RTM 版本。1703 作为 2017年一次重大的 Windows 10 更新除了改进了系统的性能和稳定性外，还带来了许多新特性、新功能。其中 MBR2GPT 对于 ITPro 十分的有价值，因为他支持从 MBR 到 GPT 的无损转换。
作为常年与桌面系统部署打交道的 ITPro，应该知道在执行 Windows 升级操作时，不支持从 MBR 到 GPT。随着 UEFI 的普及，目前大多数的系统设备都已经默认支持 UEFI，配置有固态硬盘，并且还支持快速启动，而要想完全发挥硬件特性以及更好的管理磁盘，GPT 势必成为首选。但是在以往如果要将现有电脑转换为 UEFI，就必须备份和清理用户磁盘，这给 ITPro 带来了巨大的工作量。而随着 Windows 10 创者者更新的发布，那一切都将成为历史，微软听取了广大用户的建议，在系统内置了 MBR2GPT 无损转换工具 - mbr2gpt.exe，使用该工具可以轻松的执行 MBR 到 GPT 的无损转换。该工具同时还支持 Online 模式，这意味着无需引导进入 Windows PE，即可在当前生产环境直接进行转换。
gOxiA 专门抽出时间搭建了环境对 MBR2GPT 进行了实验，效果非常之好，没有复杂琐碎的干预操作，执行执行命令即可完成，期间获得了一些宝贵经验，希望借此与大家分享，避免大家踩坑。实验环境是一台 Windows 10 创作者更新的虚拟机，Gen1 类型 MBR 启动，鉴于国内用户通常都是将引导分区和系统分区放在一个卷上，并喜欢划分多个分区，所以这台虚拟机的分区结构如下：
下来，gOxiA 直接启动命令行环境，执行 mbr2gpt.exe 进行转换，因为是 Online 模式，所以除了转换参数 /convert 外，还需附加 /allowfullos 参数。完整的命令行即：
mbr2gpt /convert /allowfullos
执行结果显示失败“Disk layout validation failed for disk 0”，难不成跟没有使用独立的引导分区有关，随后收缩系统盘空间 500MB 出来打算手工做个启动分区，由于当前磁盘分区是 4个主分区如果要再添加分区必须转化为动态磁盘，否则就要使用 GPT。
看来思路不对，问题应该还是出现在这四个主分区上，检查了日志发现了线索“Too many MBR partitions found, no room to create EFI system partition.”显然由于分区过多，导致无法创建 UEFI 引导分区。
由于是实验环境，所以直接删除了第四个分区，保留系统三个有效分区，再次执行 mbr2gpt 顺利进行了转换，过程与结果如下图所示：
最后将该磁盘分配到 Gen2 类型 UEFI 的虚拟机上启动进行测试，成功进行了转换。
另据 gOxiA 所了解国内很多企业环境下，ITPro 并没有很好的执行标准化部署，喜欢用一些陈旧的第三方工具为电脑分区格式化，还喜欢创建多分区结构来替代目录实现分类数据存储，这就为以后标准化的推进埋下了隐患，建议还是基于产品多做分析多做实践，良性的使用习惯推广不仅是对自己负责也是对用户负责！
HOWTO: 解决因配置 FolderLocations 引发的软件安装故障
HOWTO: 解决因配置 FolderLocations 引发的软件安装故障
还记得前段时间 gOxiA 分享的一篇日志“HOWTO: 解决 Windows DISM error ID3 0x80070003 故障”，由于在 Windows 安装应答文件（Unattend.xml）中配置了“FolderLocations”来重定向用户目录，导致在离线模式下使用 DISM 配置系统失败。虽然微软官方确认了这是一个已知问题，并且给出了解决方案，但是发现并不能完全解决所有问题，例如当用户在使用 Folerlocations 重定向用户目录的系统环境中安装 AutoCAD 时就会出现故障问题，如下图所示：
可以看到 AutoCAD 安装向导在许可协议界面报错“错误: 1606。无法访问网络位置 Autodesk\AutoCAD 2014\R19.1”。
根据提示搜索了 AutoCAD 官方文档也未获得准确的提示和解决办法，有网友称需要安装什么 Windows 7 补丁，其实根据排错发现引发该问题的主要根源就是因为重定向了用户目录，而 Public 这个用户目录路径未能更新到注册表响应的键值上，而这罪魁祸首还是因为 FolderLocations，Sysprep 虽然能够处理 FolderLocaltions 并成功移动 Users 目录到其他分区，但是却未能更新所有的注册表键值。
要解决这个问题，就需要手工编辑注册表，定位到如下路径，修改其下 Public 的键值，确保路径正确。
“HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders”
修改完毕后，重新启动安装程序，便可解决故障问题。gOxiA 有幸加入到了 WDG Windows 10 TAP 项目，决心将这个 Bug 提交给产品开发组，希望能彻底解决这个问题。（从排错过程看，FolderLocations 导致的 Bug 可能涉及底层一些东西，因为在 Default 相关配置数据并未存储在注册表中！）
通过 WDS 环境应用 Windows Defender Offline - 下
通过 WDS 环境应用 Windows Defender Offline
上一篇文章“通过 WDS 环境应用 Windows Defender Offline - 上”，gOxiA 分享了如何制作 Windows Defender Offline 的 ISO 镜像，而今天这篇将开始我们的主题。在 WDS 环境下应用 Windows Defender Offline（以下简称：WDO），可以极大方便用户使用 WDO，通过企业网络 PXE 引导 WDO，比起 UFD 更安全也更高效。
但是，当我们将 WDO 的启动 WIM 文件添加到 WDS Boot Image，在用户端引导 WDO 后会发现，无法正常执行扫描工作，因为 Virus and spyware definitions: Out of date，即病毒特征库过期。如此，在 WDO 启动的初始化界面实际上是在加载最新的病毒特征库。
为了进行论证对 WDO 的 ISO 进行了分析，发现在 ISO 根目录中有一个名为 mpam-fex64.exe 文件，该文件就是最新的病毒特征库，那么接下来就要搞清楚 WDO 是如何调用这个病毒特征库的，首先要看看 Winpeshl.ini 是否定义了命令行，参考下图，确实调用了 Windows Defender 相关的执行命令，从文件名看是个专为 Offline 编写的命令，而且没有加参数，gOxiA 猜测对 mpam-fex64.exe 的调用是写在内部代码里的。
既然是固化在内部代码中的，就要确定调用特征库的具体路径，以便为后续能在 WDS 中应用 WDO 奠定基础。为此使用了 Sysinternals 工具集中的 Strings 对 OfflineScannerShell.exe 进行了分析，果然不出所料，特征库名称是固定的，但是没能找到定义路径。
重新分析 ISO 文件结构发现 mpam-fex64.exe 存储位置还包含一个 FilesList64.dll，从名字看貌似与遍历有关，难不成 WDO 是通过遍历目录寻找名为 mpam-fex64.exe 的文件，既然已经走到这一步，只能实验出结果，将 WDO 的
WIM 文件通过 DISM 命令 Mount 出来，然后直接将 FileList64.dll 和 mpam-fex64.exe 拷贝到 WDO 的 WIM 映像根目录中，保存更新添加到 WDS 启动映像，找台客户端开机 PXE 引导测试，通过！！！
问题解决，以后只需要手工下载最新版的 mpam-fex64.exe 打包到 WDO 的 WIM 中即可。Windows Defender 的最新特征库可以从下面的官方网站下载到，不要忘记将下载的文件名改为 WDO 定义的名字。
Updating your Microsoft antimalware and antispyware software:
https://www.microsoft.com/security/portal/definitions/adl.aspx
