HOWTO: 统一设置 Windows 10 的文件默认关联
HOWTO: 统一设置 Windows 10 的文件默认关联
在实践 Windows 10 的标准化部署时，由于要预先安装企业常用的应用软件，有些软件用于替换 Windows 自带的应用程序，所以 IT 人员通常会对 Windows 系统的文件默认关联进行预配置。以往我们都会先在参考映像下对 Windows 的默认关联进行手工指定，然后在配合 Unattend 应答文件，启用 Copyfile 选项将参考映像的用户设置应用到默认用户配置文件，以便后续向其他用户配置做继承达到统一配置默认关联设置的目的。
其实在 Windows DISM 中提供了默认关联的参数选项，/export-defaultappassociations 用于导出当前用户的默认关联，/import-defaultappassociations 则用于导入默认关联。
IT 人员可以现在参考映像系统环境下手工指定各文件的默认关联，然后使用如下命令行导出默认关联设置，以便后续进行导入。
dism /online /export-defaultappassociations:%userprofile%desktopdefappassoc.xml
在得到默认关联设置数据后便可导入其他映像或正在使用的系统中。例如对于一个脱机映像，我们可以执行如下命令进行导入：
dism /image:c: /import-defaultappassociations:c:defappassoc.xml
而对于用户正在使用的系统，可以借助组策略来进行配置，该选项位于：计算机配置-管理模板-Windows组件-文件资源管理器-设置默认关联配置文件，具体参考下图：
此外，我们也可以借助 WICD（Windows Imaging and Configuration Designer） 生成配置包供 Windows 10 用户使用，此法更适合通过网络传递，例如通过邮件方式发送给远端用户自助式导入配置。
更正说明：以上ICD部分截图有误，具体请参考“HOWTO: 使用预配置包为 Windows 10 设置默认应用关联”。2017年5月12日
Windows 10 Creators Update OOBE 重启故障
Windows 10 Creators Update OOBE 重启故障
Windows 10 Creators Update，即创作者更新（v1703 Build 15063）于 4月11日面向公众发布并推送。在经历了两年的洗礼，Windows 10 在质量和稳定性方面都有了极大的改进。众多企业用户也开始着手评估 Windows 10 的部署工作。
gOxiA 在去年年底完成了 Surface Pro 4 的 Windows 10 Pro v1607 的企业标准化部署工作，目前正进行 Windows 10 Ent 2016 LTSB 以及 Windows 10 Pro v1703 的评估。2016 LTSB 因为基于 v1607 所以评估过程相当顺利，但是 Windows 10 Pro v1703 却遭遇到了诡异的问题，大致的环境是一台基于 1703 ISO 安装的虚拟机作为参考映像，在系统审计模式下进行了标准化的定制，在参考映像配置完成后，使用 Unattend 配合 Sysprep 对系统重新封装，之后测试阶段都很正常，但是 OOBE 阶段提示“为什么我的电脑重启了”这样的提示，必须手动执行“下一步”才能继续，导致自动化部署会因此中断，但是在下一步继续后，系统还是能够正常进入桌面执行后续部署序列，而且系统部署完毕后也未发现其他异常。
针对该问题，排查了 setupact.log、setuperr.log 等安装日志，并未发现相关的异常和警告事件，无奈只能从 Unattend 下手逐项排查（PS：1703 和 1607 的应用和设置环境几乎相同），分别剔除 Oobesystem、Specialize 阶段的配置，几经折腾没有任何进展，最后干脆不加载 Unattend，结果故障依旧。既然如此，那么问题肯定出在参考映像系统环境上，这个初步的结果也算是一个里程碑。
分析参考映像系统环境，排除掉第三方的普通应用程序，值得关注的就只剩下国产的某安全软件，其实它也就是个“流氓性质”的 PC 管理应用，披着安全和管理的外衣，“私下干着不为人知的事情”，只是无奈于产品选型，否则坚决不会选择这类应用部署到企业环境。
孰是孰非，测试结果说话！还原到 Build Ready - Audit 状态，卸载该软件，重新执行 Sysprep 加载 Unattend 进行测试，经过漫长的等待，终于等到 OOBE，一切正常步步自动执行下去直至进入桌面，果然是第三方安全管理软件的原因，于是导入捕获映像，使用 MDT 任务序列再次跑了一遍，至此排查近 1周的问题终于得到了解决。
最后在普及一下，Windows 10 Defender 内置与系统，支持组策略管理，性能、稳定性、兼容性都相当出色，IT 人员不妨好好考虑一下！！！
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 并没有很好的执行标准化部署，喜欢用一些陈旧的第三方工具为电脑分区格式化，还喜欢创建多分区结构来替代目录实现分类数据存储，这就为以后标准化的推进埋下了隐患，建议还是基于产品多做分析多做实践，良性的使用习惯推广不仅是对自己负责也是对用户负责！
