win10creatorsupdate1703

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 阶段提示“为什么我的电脑重启了”这样的提示,必须手动执行“下一步”才能继续,导致自动化部署会因此中断,但是在下一步继续后,系统还是能够正常进入桌面执行后续部署序列,而且系统部署完毕后也未发现其他异常。

snipaste20170413_144006

        针对该问题,排查了 setupact.log、setuperr.log 等安装日志,并未发现相关的异常和警告事件,无奈只能从 Unattend 下手逐项排查(PS:1703 和 1607 的应用和设置环境几乎相同),分别剔除 Oobesystem、Specialize 阶段的配置,几经折腾没有任何进展,最后干脆不加载 Unattend,结果故障依旧。既然如此,那么问题肯定出在参考映像系统环境上,这个初步的结果也算是一个里程碑。

        分析参考映像系统环境,排除掉第三方的普通应用程序,值得关注的就只剩下国产的某安全软件,其实它也就是个“流氓性质”的 PC 管理应用,披着安全和管理的外衣,“私下干着不为人知的事情”,只是无奈于产品选型,否则坚决不会选择这类应用部署到企业环境。

        孰是孰非,测试结果说话!还原到 Build Ready - Audit 状态,卸载该软件,重新执行 Sysprep 加载 Unattend 进行测试,经过漫长的等待,终于等到 OOBE,一切正常步步自动执行下去直至进入桌面,果然是第三方安全管理软件的原因,于是导入捕获映像,使用 MDT 任务序列再次跑了一遍,至此排查近 1周的问题终于得到了解决。

        最后在普及一下,Windows 10 Defender 内置与系统,支持组策略管理,性能、稳定性、兼容性都相当出色,IT 人员不妨好好考虑一下!!!

win10creatorsupdate1703

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 启动,鉴于国内用户通常都是将引导分区和系统分区放在一个卷上,并喜欢划分多个分区,所以这台虚拟机的分区结构如下:

snipaste20170410_083039

        下来,gOxiA 直接启动命令行环境,执行 mbr2gpt.exe 进行转换,因为是 Online 模式,所以除了转换参数 /convert 外,还需附加 /allowfullos 参数。完整的命令行即:

mbr2gpt /convert /allowfullos

        执行结果显示失败“Disk layout validation failed for disk 0”,难不成跟没有使用独立的引导分区有关,随后收缩系统盘空间 500MB 出来打算手工做个启动分区,由于当前磁盘分区是 4个主分区如果要再添加分区必须转化为动态磁盘,否则就要使用 GPT。

snipaste20170410_083403

        看来思路不对,问题应该还是出现在这四个主分区上,检查了日志发现了线索“Too many MBR partitions found, no room to create EFI system partition.”显然由于分区过多,导致无法创建 UEFI 引导分区。

snipaste20170410_093646

        由于是实验环境,所以直接删除了第四个分区,保留系统三个有效分区,再次执行 mbr2gpt 顺利进行了转换,过程与结果如下图所示:

snipaste20170410_090358

        最后将该磁盘分配到 Gen2 类型 UEFI 的虚拟机上启动进行测试,成功进行了转换。

        另据 gOxiA 所了解国内很多企业环境下,ITPro 并没有很好的执行标准化部署,喜欢用一些陈旧的第三方工具为电脑分区格式化,还喜欢创建多分区结构来替代目录实现分类数据存储,这就为以后标准化的推进埋下了隐患,建议还是基于产品多做分析多做实践,良性的使用习惯推广不仅是对自己负责也是对用户负责!

Co3p9r4XYAAb_t8

HOWTO: 解决因配置 FolderLocations 引发的软件安装故障

        还记得前段时间 gOxiA 分享的一篇日志“HOWTO: 解决 Windows DISM error ID3 0x80070003 故障”,由于在 Windows 安装应答文件(Unattend.xml)中配置了“FolderLocations”来重定向用户目录,导致在离线模式下使用 DISM 配置系统失败。虽然微软官方确认了这是一个已知问题,并且给出了解决方案,但是发现并不能完全解决所有问题,例如当用户在使用 Folerlocations 重定向用户目录的系统环境中安装 AutoCAD 时就会出现故障问题,如下图所示:

snipaste20170303_102751

        可以看到 AutoCAD 安装向导在许可协议界面报错“错误: 1606。无法访问网络位置 Autodesk\AutoCAD 2014\R19.1”。

        根据提示搜索了 AutoCAD 官方文档也未获得准确的提示和解决办法,有网友称需要安装什么 Windows 7 补丁,其实根据排错发现引发该问题的主要根源就是因为重定向了用户目录,而 Public 这个用户目录路径未能更新到注册表响应的键值上,而这罪魁祸首还是因为 FolderLocations,Sysprep 虽然能够处理 FolderLocaltions 并成功移动 Users 目录到其他分区,但是却未能更新所有的注册表键值。

snipaste20170303_135943

        要解决这个问题,就需要手工编辑注册表,定位到如下路径,修改其下 Public 的键值,确保路径正确。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders

snipaste20170303_140250

        修改完毕后,重新启动安装程序,便可解决故障问题。gOxiA 有幸加入到了 WDG Windows 10 TAP 项目,决心将这个 Bug 提交给产品开发组,希望能彻底解决这个问题。(从排错过程看,FolderLocations 导致的 Bug 可能涉及底层一些东西,因为在 Default 相关配置数据并未存储在注册表中!)

分页: 45/147 第一页 上页 40 41 42 43 44 45 46 47 48 49 下页 最后页 [ 显示模式: 摘要 | 列表 ]